I wonder, instead of “bad things” in an atomic block falling back to undefined behavior, can we mandate that they fall back to well defined behavior that is observably equivalent to a global lock?

This wouldn’t unnecessarily limit implementations IMO. Any scheme that attempts to parallelize atomic blocks will internally support aborting and retrying a transaction, so the scheme should always be capable of a well-defined fallback to a global lock, for example if you try to do unsupported I/O in a transaction.

Tim

> On Jan 9, 2020, at 4:06 PM, Jens Maurer via SG5 <sg5_at_[hidden]> wrote:
>
> Hi!
>
> After today's teleconference, I couldn't resist, so
> I created a draft TS for TM-light, mostly copying
> from Victor's Google doc. See attached.
>
> The new part is in 8.8, where we decree implementation-defined
> behavior when "bad" things are evaluated inside an atomic block.
>
> Possibly surprising changes vs. the status quo of the discussion:
>
> - constexpr functions only
> (as explained in the teleconference, the compiler might not retain
> other functions from the same translation unit)
>
> - throw-expressions are forbidden entirely
> (Did we want to require support for throw/catch within the atomic
> block? Seems more-than-minimal.)
>
> - Coroutines are forbidden entirely.
> (I haven't seen talk about them vs. TM. Also, they have funny
> control flow.)
>
> This would be in time to submit to the pre-Prague meeting,
> for SG1 and EWG amusement there, if I get approval on this list
> until Monday.
>
> I've added all participants to the authors list, please complain
> if that's wrong.
>
> Jens
> <tm-lite.html>
> --
> SG5 mailing list
> SG5_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg5