Submitted:

https://isocpp.org/files/papers/P2066R8.html

Ignored Michael Scott's comment as too complicated to explain,
and subsumed by the existing hazy wording below.

Jens


On 12/07/2021 18.44, Hans Boehm wrote:
> Here's a draft. Could you please incorporate it? I did not yet run it through an html checker.
>
> I believe we were also asked to address questions about locales?
>
> <h>Notable design decisions.</h>
> <p>
> A more detailed rationale for many of the decisions made here is given in
> <a href="http://wg21.link/p1875 <http://wg21.link/p1875>">P1875</a>. Here we quickly summarize design decisions leading
> to this proposal. These are generally motivated by the desire to produce a much simpler,
> more easily implementable specification. Except for the last two, these have been stable
> since the original SG1 discussion. All were part of the proposal during the final EWG
> discussion.
> <ul>
> <li> This is a language, not library, proposal.
> Passing lambda expressions to a "run this as a transaction" function was not well-liked, and has
> issues with varargs access. An RAII-based library facility was considered, but also disliked by
> SG1, this time, among other issues, because it waas unclear what this would mean if the RAII
> object was not stack-allocated.</li>
> <li> We want to leave a lot implementation-defined for the TS, to encourage implementations,
> and support experimentation. We do not want to again end up with a TS that is difficult to
> implement usefully, and thus fails to attract implementations.</li>
> <li> We want to focus on simple implementations that are based in hardware transactional memory,
> and/or use the
> trivial global lock implementation. We expect HTM implementations that fall back on a global
> lock to dominate in practice, at least initially. We want to allow more elaborate implementations
> based on software transactional memory but, unlike the current TS, we do not want to require
> such elaborate implementations.</li>
> <li> There is no support for explicitly declaring transaction-safety. This is a major simplification
> over the current Technical Specification. This does not matter for HTM or gloabl lock implementations,
> which do not need to instrument code. It does make it more difficult to extract good performance
> from software transctional memory implementations, but there is agreement that the simplification is worth
> the trade-off.</li>
> <li> Exceptions may not escape from transactions. This dodges many complicated issues about whether
> transactions should commit or abort and, in the latter case, how exception objects themselves survive
> transaction aborts.</li>
> <li> The "atomic do {...}" syntax. This was the most natural syntax we (mostly EWG) could come up with that
> appears to be easily parseable, and does not require a new keyword. It was "atomic {...}" during SG1 discussions.
> "atomic do" reflects a non-unanimous consensus in EWG.</li>
> <li> Allow <code>malloc (and hence non-escaping exceptions, and much more of the standard library) inside transactions.
> This was a recent change, but preceded the last EWG discussion. We previously thought that we could get by with
> very restricted transactions, so long as they were sufficiently general to implement N-way compare_exchange.
> Closer examination by SG5 determined that was problematic since the load operations preceding the compare_exchange
> transaction would also need to be transactions, making them expensive, at least without heroic implementation
> effort. Thus we concluded that it was desirable to again allow much of the standard library inside
> transactions. (Also discussed in more detail in P1875, but more as an open issue.)</li>
> </ul>
>
> On Mon, Jun 28, 2021 at 6:17 PM Hans Boehm <boehm_at_[hidden] <mailto:boehm_at_[hidden]>> wrote:
>
> Will do. Let's go ahead and cancel the meeting.
>
> On Mon, Jun 28, 2021, 1:01 PM Jens Maurer <Jens.Maurer_at_[hidden] <mailto:Jens.Maurer_at_[hidden]>> wrote:
>
> On 28/06/2021 04.48, Hans Boehm via SG5 wrote:
> > We have a meeting scheduled for Tuesday. I don't think anything has happened in the interim that really requires discussion. Unless someone else has an agenda item, I suggest we cancel again. (If you received an earlier pair of cancel/reinstate requests from Google calendar, my apologies.)
> >
> > We have a scheduled meeting with LEWG Aug 17th at 10a.m. We need a small update to P2066 before then, at Bryce's (LEWG Chair) request, basically summarizing past decisions. Jens- Should I slightly expand what I wrote in the May 25 message? Can you incorporate it then, so we have something in the July mailing?
>
> If you have something that I can then cut/paste into P2066, that would be most
> helpful.
>
> Jens
>