Hi Everyone,

Victor, Michael, and I have been working on a new draft of the document.
Please have a look:
https://docs.google.com/document/d/1GN_97YpPmxs9byKpzzlxusNtSapCFl6Bm9NdCExrl0U/edit

- Mike

On Mon, Dec 14, 2020 at 8:38 PM Hans Boehm via SG5 <sg5_at_[hidden]>
wrote:

> Let's meet, at least briefly, tomorrow, to see how things stand, and if
> there's been any progress.
>
> Usual coordinates:
>
> 8-9am PST, or 11am-12 EST
>
> meet.google.com/sbj-cvgh-vnd
> or
> ‪(US) +1 208-925-0196‬ PIN: ‪255 542‬#
>
> On Tue, Nov 17, 2020 at 1:01 PM Hans Boehm <boehm_at_[hidden]> wrote:
>
>> Attendees: Hans Boehm, Victor Luchangco, Michael Scott, Mike Spear
>>
>> Some continuation of email discussion about using seqlock-like
>> implementations to accelerate read-only critical sections.
>>
>> Two flavors:
>> Increment counter on every writing transaction. E.g. single global
>> seqlock. Supports multi-read read-only transactions.
>>
>> Increment counter on HTM fallback to support fast single-word read
>> transactions.
>>
>> Some discussion about prior PODC work to support fast read-only
>> transactions. [ I wasn't able to locate the paper based on what I remember
>> from the discussion. We might have gotten something
>> wrong? ]
>>
>> Switched back to malloc discussion
>>
>> The core change is that we would allow throwing of exceptions in
>> transactions. Get UB only if the exception escapes the transaction.
>> Catching it in the transaction would be fine.
>>
>> Victor suggests that special handling for OOM may be worth it.
>>
>> The programmer could still let out-of-memory information escape by
>> storing the OOM information someplace. We do not want to specify that
>> exceptions commit transactions, even though that variant is easy to
>> implement.
>>
>> How much change is required to allow malloc()?
>>
>> Probably not too much change to spec. Mostly the list of transaction-safe
>> standard library facilities becomes much longer.
>>
>> Discussion of deferring delete. Don't want to defer destructor
>> invocation, but actual deallocation could be deferred. May be necessary for
>> STM, but we probably don't want to mention this in the spec. Not an issue
>> for HTM or SGL implementations.
>>
>> TODO:
>>
>> Still need paper justifying the change with respect to allowing malloc().
>>
>> Mention implementation techniques for low-cost read-only transactions in
>> the background paper, and possibly add their utility to the list of TS
>> questions. They might make "atomic do{}" more interesting for some
>> read-mostly applications, even in the absence of HTM.
>>
>> We still need a volunteer to implement the "atomic do" syntax.
>>
>> Next meeting: Dec. 15, 8am PST
>> 
>> Join with Google Meet
>> meet.google.com/sbj-cvgh-vnd
>> Join by phone
>> ‪(US) +1 208-925-0196‬ PIN: ‪255 542‬#
>>
>>
>> --
> SG5 mailing list
> SG5_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg5
>