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