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‬#
>
>
>