C++ Logo


Advanced search

[SG5] December 15 meeting

From: Hans Boehm <boehm_at_[hidden]>
Date: Mon, 14 Dec 2020 17:38:38 -0800
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

‪(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.
> 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‬#

Received on 2020-12-14 19:38:52