Subject: Re: Suggested draft TS for TM-light
From: Tim Sweeney (tim.sweeney_at_[hidden])
Date: 2020-01-09 15:18:12
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.
> On Jan 9, 2020, at 4:06 PM, Jens Maurer via SG5 <sg5_at_[hidden]> wrote:
> 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.
> SG5 mailing list
SG5 list run by herb.sutter at gmail.com
Older Archives on Google Groups