Hacker News Reader

Comment by schmichael | Hacker News Reader

Does anyone have experience debugging/profiling highly contended critical sections of STM vs a more traditional mutex implementation? At the end of the day something has to mediate concurrent access to shared memory, there’s no free lunches, and mutexes are so well optimized, profiled, and understood. I’m unclear if the same applies to STM where a transaction may need to be retried an unbounded(?!) number of times.

View on HN

Yes. The mediator in this case is the scheduler. The one that actually calls the asynchronous block. Potentially retrying it if it fails. In the OP’s code, there’s atomic blocks, sequential execution of blocks, stateful blocks, etc for ensuring singular access at a time.

The meat here is scheduler.cpp. It uses std::coroutines.

This is like async/await in other languages. The scheduler has a queue of work(coroutines) and a pool of threads(N>0) to execute those on.

In this case, messages are passed between work that contains the data. No locks are required at the expense of memory footprint.

Thanks!

So the scheduler serializes execution of critical sections?

> In this case, messages are passed between work that contains the data. No locks are required at the expense of memory footprint.

Are messages copied or moved? If moved is there compile time checking for ownership or runtime debugging tools?

https://en.cppreference.com/w/cpp/language/coroutines

Actually, for starvation-free STMs, transactions will retried a _bounded_ number of times. One example is 2PLSF, but there are several others https://zenodo.org/record/7886718

Interesting, thanks! It’s been years since I’ve read up on STM.

Reply on news.ycombinator.com