[codepie]

The thread example given in article is only limited to a single writer and multiple readers. Things get interesting when you want to have lock free concurrency with multiple readers and writers. One of the famous techniques is using software transactional memory (https://en.m.wikipedia.org/wiki/Software_transactional_memor...). But it hasn't really caught up in the industry and it still exists within academia.

The existing lock free concurrency solutions are not mature enough to replace locks. I like this analogy of what garbage collection is to memory is STM is to memory(https://homes.cs.washington.edu/~djg/papers/analogy_oopsla07...).

[signa11]

> ... But it hasn't really caught up in the industry and it still exists within academia...

acm had this article a while back: http://pages.cs.wisc.edu/~cain/pubs/cascaval_cacm08.pdf

may you please comment on that ? thank you !

[gpderetta]

There are lock free algos that support multiple writers. The reason they are sometime avoided is that, in addition of being often more complicated, they usually scale badly; that's inherently true with any algorithm violating the single writer principle, not just with lock-free algos; that's true with STM as well.

[saas_co_de]

Intel has TSX https://software.intel.com/en-us/node/524022

I have never used it though and I am not sure who does.

[convolvatron]

I wish this were more useful. The real sticking point for me is that you can run out of transaction contexts - which means you have to have a full software implementation as backup.

the only case I can think of where I would actually use the thing is if I already had an STM runtime and I wanted to cut down some of the constant time overheads.

the other problematic aspect s that transaction scheduler policy is pretty important for contended performance and as part of the broader system design. in this case you have to live with whatever intel gives you