Item — HN Reader

"...No, no, no. If you are writing multithreaded programs, you _will_ have locks, period. The question is whether you explicitly use them or if they are hidden somewhere in your libraries, frameworks, etc...."

That is not true. Lock-free data structures exist and are applicable to many multi-threading use cases. For a super primer see https://en.wikipedia.org/wiki/Non-blocking_algorithm and if you are really interested, read about Transactional memory - http://dl.acm.org/citation.cfm?id=165164, and then "The Art of Multiprocessor Programming" (it is a text book) by Herlihy and Shavit.

3 comments

I have been following transactional memory since 2004 or something like that, it's great as it solves the locking problem on that specific abstraction level. It does not solve the general problem of synchronization, though. See my other comment in this thread. Locking problem != making sure that a 64-bit value will be left in an inconsistent state.

You have followed it longer than I have then. My gut reaction is more to the universal nature of your claim that I quoted. It is a goal to have practical large systems that need no locks. Current operating systems in production may not be there yet, but it is not proven that it is impossible to create a system that is entirely lock free.

Reasoning about the correctness of lock-free concurrency is much more difficult than doing the same for sequential algorithms, and gives the lie to the original author's claim that successful concurrent programming is just a matter of avoiding mutable global state.

The quote seems to use "lock" to mean any locking provided by your primitives, he probably includes the atomic instructions too since they have locking in hardware.