3 ms·
I think this guy was too kind to STM. Otherwise I largely agree. Despite being a C++ programmer I like using high level abstraction. I like being able to write
by sqeaky 10y ago
I think this guy was too kind to STM. Otherwise I largely agree.
Despite being a C++ programmer I like using high level abstraction. I like being able to write a few lines and knowing what the result will be and having the computer just figure it out the details. Despite that I really want those abstractions to be as close to zero cost as possible. I also want to precisely know how to work with the contract the spec demands and the implementation reality requires, because performance is all too often a real concern for me.
STM has never had a role in any of that because it tries to be a panacea. It tries to fix everything for everybody. There is no way it can be an optimal (or even reasonable) solution for most problems).
I think me and the author would agree that naked mutexes are the gotos of threaded algorithms. Just as we replaced gotos with several kinds of loops, several kinds of functions, classes, lambdas and countless other more expressive tools, we will replace naked mutexes with a host of other tools. Have something you just want to run on some other hardware and get the answer from, try a future/promise. Have N units or identical work, try a parallel for or a one of the many GPU executors. Have a complex dependency chain of heterogeneous work, build a DAG of actors or other automata. Need something else, perhaps your threading primitive hasn't been invented yet.
- jhartmann 10y agoI think you should also mention work queues and producer / consumer thread pools. These are very powerful concepts you don't mention here, and they are often the first tool I use. You very often don't need anything else.