Tim, Herb -

As you may have seen, SG5 generated an initial proposal for a simplified
transactional memory facility. See wg21.link/p1875. This was reviewed by
SG1. See http://wiki.edg.com/bin/view/Wg21belfast/P1875r0, or my short
summary below. We'd be very interested in any additional reactions you may
have.

One additional concern, brought up in later SG5 discussions, is that we're
not terribly clear on the perception/status of various hardware
transactional memory (HTM) facilities, in light of the fact that current
best effort HTM facilities seem ideally suited for side-channel attacks
that need to inspect cache state. Given that this facility is becoming more
focused on exposing hardware support, this seems relevant. None of us have
a good idea where hardware vendors are going with this.

Thanks!

Hans

My summary of SG1 reaction to proposal [with some comments from subsequent
SG5 discussion] :
-------------------------------------------------------

Generally people seemed positively inclined. People liked the idea of
cutting back on the original TS. There weren't really any requests to put
specific pieces back.

Many people would like a mechanism that allows relatively low-level
portable access to HTM facilities. That generally seemed to be the highest
priority, and is consistent with what we've heard before.

Along the same lines, there was apprehension about not being able to get
feedback as to whether a transaction was actually executing in HTM. Several
people wanted a way to explicitly observe retries. I think especially the
HPC community needs something like that to diagnose the performance
problems that otherwise arise from a single global lock fallback.

There was concern that the RAII-based syntax allowed semi-nonsensical
constructs that would be hard to handle in the implementation. What happens
if the transaction_scope object is allocated somewhere other than on the
stack? How would you implement that? Even in cases in which it is owned by
a stack object, and thus does kind-of make sense, it seems problematic.

We did end up taking a quick poll about the two other options in SG1, and
it was 8 to 3 in favor of language syntax, with a significant number of
people not voting. I have little confidence that this would go the same way
in other groups. I may ask around to get some impression of how this might
go in EWG, which actually has more of a voice here. [ SG5 is happy with
going the syntax route, justified by varargs issues with the lambda
approach, and SG1 concerns about the RAII approach. ]

There was some interesting discussion of co_await in transactions, and
"coroutines" in general. (C++ "coroutines" are very customizable, and may
not behave much like actual coroutines. So this question is probably a bit
more important and subtle than it seems at first glance.) We need to think
about this when drafting wording. I currently don't have good intuitions
about this. [ SG5 consensus afterwards was to initially not require support
for anything coroutine-related in transactions. The current plan is to
allow implementations to support anything they want in transactions anyway.
]

The abuse of constexpr to define a minimal set of transaction-safe library
facilities was viewed with suspicion. It was pointed out that we would
probably need to list some exceptions in both directions. (Which I think is
OK, since I view this as an opportunistic specification mechanism to avoid
specifying transaction-safety for every standard library routine.) I did
not hear an actual better alternative.