3 ms·
Does anyone have experience debugging/profiling highly contended critical sections of STM vs a more traditional mutex implementation? At the end of the day some
by schmichael 3y ago
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.
- gabereiser 3y agoYes. 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.
- schmichael 3y agoThanks! 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?
- gabereiser 3y agohttps://en.cppreference.com/w/cpp/language/coroutines https://en.cppreference.com/w/cpp/language/coroutines
- pramalhe 3y agoActually, 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 https://zenodo.org/record/7886718
- schmichael 3y agoInteresting, thanks! It’s been years since I’ve read up on STM.