Date: Tue, 17 Nov 2020 13:01:48 -0800
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#
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#
Received on 2020-11-17 15:02:02