C++ Logo


Advanced search

Subject: Re: December 15 meeting
From: Michael Spear (mfs409_at_[hidden])
Date: 2021-01-11 11:06:23

Hi Everyone,

Victor, Michael, and I have been working on a new draft of the document.
Please have a look:

- Mike

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

> 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 list run by sg5-owner@lists.isocpp.org

Older Archives on Google Groups