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