Uh oh, I might be getting there late. We may need a digital baton to pass
:)

On Mon, Jan 11, 2021 at 12:56 PM Michael L. Scott <mlscott_at_[hidden]> wrote:

> FYI, I’m going to have to leave the meeting by 11:30 tomorrow; sorry!
>
> - Michael
>
> On Jan 11, 2021, at 12:06 PM, Michael Spear via SG5 <sg5_at_[hidden]>
> wrote:
>
> 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
>>
> --
> SG5 mailing list
> SG5_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg5
>
>
>