Attendees:
Hans Boehm
Bronek Kozicki
Victor Luchangco
Jens Maurer
Michael Scott
Mike Spear
Michael Wong

We discussed feedback from EWG

The initial discussion was about alternate keywords or
context-sensitive-keywords to replace the current ambiguous atomic {}
syntax.

Bronek reminded us of the difficulty with "do atomic {":

do do atomic { ... } while (...) is legal and hard to parse.

Explained that even a relatively obscure new keyword like tm_atomic was
likely to cause problems with existing codebases.

There was lukewarm consensus (ambivalence?) on atomic do.

Jens summarized EWG discussion and explained why constexpr is not a good
indicator of transaction-safety. We increasingly have constexpr functions
that test for a constexpr constant and execute different, possibly
non-transaction-safe, code in other cases.

Talked about what we really needed to be transaction-safe.

memcpy, memset should be.

STL containers are the problem.

For something like vector, it's possible to get a pointer to a C array
outside the transaction. But that fails if multiple containers are
accessed, with one referring to the other.

Traits are OK. Numeric limits, too. Constexpr values in general. What's the
best way to characterize purely compile-time expressions?

For something like std::vector, should we be limited to accessors? Can we
grow containers inside transactions? Should malloc/new be supported?

General initial reaction: Should not be required.

Mike Spear argues for malloc/new. Easily supported for HTM and global lock.
For STM, not that much more work is required.

What about throwing OOM? Currently no throws in transactions are allowed,
even non-escaping ones.

Action Items:
Jens will generate new revision with minimal guaranteed standard library
support.
Mike Spear will try to write up a short paper describing why malloc support
is easy.

Next meeting scheduled for 8:00 PDT, Sept. 22