On 21/10/2020 03.16, Hans Boehm via SG5 wrote:
> Mike Spear: What can you actually do with the p2066 proposal?
>
> Michael Scott: implement lock-free data structures like linked lists that read without a lock, and then transactionally update it at the right place.
>
> Mike Spear: No, because the initial reads can't be on atomic data.
>
> Can't really use these transactions as an NCAS replacement. All read accesses preceding NCAS would also have to be transactional, which is too expensive for something like Intel HTM. Transactions cost as much as locks, so surrounding every read by one is not practical.
>
> Victor L.: Transactional reads could work for tree traversal followed by update, which is probably more common.
>
> Clarification that this avoids contention in an HTM context, but still has latency issues even in the uncontended case.
>
> Discussion of double-checked locking, with a similar conclusion. It's not practical to put the initial read in a transaction.
>
> We unfortunately concluded that we either need more of a usability argument for what we have, or probably a revision of both the design and wording documents to allow new + caught exceptions. If we had the latter, most of the STL data structures could become usable in transactions. Given that roll-your-own data structures don't seem terribly viable, that would give us a much better usability argument.

The fact that even reads need to be inside a transaction to avoid data
races with updates was part of the SG5 TM design since the beginning,
so I'm slightly baffled to see this surface as a "back to square one"
surprise.

Why would the ability to use STL data structures in a transaction
help this case in any way?

Jens