>> which works perfectly for a few dozens to low hundreds of threads It's a lot more complicated that than. It depends heavily on how many threads are writing

>> which works perfectly for a few dozens to low hundreds of threads It's a lot more complicated that than. It depends heavily on how many threads are writing to the shared memory and how often. If the workload is write-heavy from many threads then then it can really add up. Also, if there are multiple shared memory locations which all use mutexes, it adds up as well. Shared memory offers diminishing returns as the logic becomes more complex. Often, it's better to simply design the system in such a way that it removes or at least minimizes interactions and data sharing between different threads or processes. With such designs, often the overheads of IPC communication become very low. Some engines like Node.js are focused around IPC as the main mechanism for sharing data between different processes. It produces relatively elegant code which is easy to follow and this design makes it relatively easy to identify the bottlenecks. I agree that the approach I was suggesting is probably not ideal for low-concurrency situations (like games as I mentioned in my last comment) but I still think that shared memory access mechanisms are not elegant. That said, I find that programming solutions which try to squeeze every last drop of performance out of the hardware are rarely elegant architecturally.