3 ms·

This is equivalent to giving up a lock in between though, I think.

• fc417fc802 2y ago
  Maybe I misunderstood. I took the first bullet to refer to wrapping operations in a lock and the second to refer to single writer multiple reader. At least in the single writer scenario it all breaks down if a lock free reader requires multiple items that are related to one another. It's an easy oversight to make though. Fixing it sucks because you usually have to go and add locking to your previously fast and efficient lock free setup.
  • pbh101 2y ago
    It can also break if the read implementation has mutable side effects, e.g. rebalancing. Java HashMap used to have this causing an infinite loop. I haven’t looked recently but my guess is it still does. https://mailinator.blogspot.com/2009/06/beautiful-race-condition.html https://mailinator.blogspot.com/2009/06/beautiful-race-condi... ‘Not thread safe’ really means ‘not thread safe’.
  • sunshowers 2y ago
    > At least in the single writer scenario it all breaks down if a lock free reader requires multiple items that are related to one another. It's an easy oversight to make though. This is true -- generally the solution to this is to ask for everything in a single message.
• gf000 2y ago
  I mean, that's the "art of the deal". If you have a lock for all eternity, then you have a single owner, and are practically single-threaded. The hard part is exactly all the combinations locks can be hold and given up, which will have a non-trivial number for more complex programs/data structures. That's where modeling software can help by iterating over all the possible cases.