3 ms·

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

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_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.pdf https://homes.cs.washington.edu/~djg/papers/analogy_oopsla07...).

signa11 9y ago
> ... 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 http://pages.cs.wisc.edu/~cain/pubs/cascaval_cacm08.pdf may you please comment on that ? thank you !
gpderetta 9y ago
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 9y ago
Intel has TSX https://software.intel.com/en-us/node/524022 https://software.intel.com/en-us/node/524022 I have never used it though and I am not sure who does.
- convolvatron 9y ago
  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

signa11 9y ago

> ... 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 http://pages.cs.wisc.edu/~cain/pubs/cascaval_cacm08.pdf may you please comment on that ? thank you !

gpderetta 9y ago

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 9y ago

Intel has TSX https://software.intel.com/en-us/node/524022 https://software.intel.com/en-us/node/524022 I have never used it though and I am not sure who does.

convolvatron 9y ago
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