CppCon is done and I had a great time, an exhausting time, but great nonetheless. I gave my talk on STM in both lightning format and as a more relaxed open content session. In the open content session I was able to take questions from the audience (the lightning format didn’t afford me that luxury) and one audience member asked about how we decided what variables to transact since our system is explicit. I gave a bit of a hand-wavey answer that it was a design issue – an answer that while he seemed satisfied with, he also seemed a bit disappointed in. Of course I came up with a better answer later that evening – long after the talk was over – but then never I saw him again during the conference. So on the off chance that he’s reading this here’s a better answer:
We transact anything that will be shared between threads that isn’t be protected by some other method (e.g. locks or atomics). The question then shifts to “at what level do you transact things?” We could store single values in their own STM variable object or combine a bunch of values into one object and store the aggregate object in a STM variable. That is a design issue that is akin to deciding between fine-grained and corse-grained locking(though it’s an easier issue to deal with in my experience). In an implicit system this decision is taken out of your hands, anything you touch in a transaction becomes part of the transaction, which can have implications for how you need to structure your code. So while STM can simplify shared-memory multi-threaded programming, it doesn’t make it simple – I doubt anything ever will.