3 ms·

Even pre C++11 scoped locks where commonly used - eg via boost::lock_guard. But RAII locks just solve one problem from a huge bag of potential problems: Forgett

Even pre C++11 scoped locks where commonly used - eg via boost::lock_guard. But RAII locks just solve one problem from a huge bag of potential problems: Forgetting to unlock in all path. They won’t fix deadlocks, forgetting to synchronize at all, inconsistent locking, race conditions and other pain points.

hinkley 4y ago
'Security primitives' aren't an accident of naming. Concurrency mechanisms we've had from the 70's are still contentious precisely because they don't compose. Everything is great when you have one or two concerns trying to do things in parallel, but when your whole app is doing it... it is a rare person who can figure out why things are breaking in magical ways. Most people are overwhelmed by the prospect or the number of things they have to consider. If SOLID principals apply in spades to regular code, then there's a power law for concurrent code. When Simon Peyton Jones was working at Microsoft Research on Software Transactional Memory, he prefaced practically every video/interview with this uncomfortable fact. Given the lack of traction, I can only assume that some of the corner cases of STM proved to be intractable, and my read on the domain is that borrow semantics are trying to arrive at a similar place by different avenues. I'm very interested to see 1) how far borrow semantics get, in the same way that type inference simplifies generics, and 2) what someone tries next, particularly if it involves synthesizing elements from different schools.
- jerf 4y ago
  The problem with STM is A: You can not retrofit it on to an existing language and B: The language you build to support it looks an awful lot like Haskell, particularly the careful separation between pure and IO code. And as of 2022, most programmers are not willing to program that way. I do a lot of concurrency stuff, and my go-to is one form or another of message passing. It isn't a miracle cure, but it turns the exponentially complicated issues with lock-based systems into polynomial ones, and that's at least something you have a prayer of managing. They compose better. I'm not sure I'd say they compose well, and someone may yet find an even better model, but they compose better. (STM doesn't seem to be that model. As the transactions inevitably get larger over time they start getting complicated.)
vitus 4y ago
> forgetting to synchronize at all, inconsistent locking At least for these two classes of categories, mutex usage at Google is broadly paired with compiler-enforced annotations to enforce that _all_ accesses to mutex-guarded member variables are done while holding the appropriate mutex. https://abseil.io/docs/cpp/guides/synchronization#thread-annotations https://abseil.io/docs/cpp/guides/synchronization#thread-ann... (While yes, it can also help with deadlock avoidance as well, that tends to be trickier to enforce across the board, especially if the mutexes in question belong to different objects. There's separate deadlock detection baked into Abseil that's used primarily in non-production builds.)

hinkley 4y ago

'Security primitives' aren't an accident of naming. Concurrency mechanisms we've had from the 70's are still contentious precisely because they don't compose. Everything is great when you have one or two concerns trying to do things in parallel, but when your whole app is doing it... it is a rare person who can figure out why things are breaking in magical ways. Most people are overwhelmed by the prospect or the number of things they have to consider. If SOLID principals apply in spades to regular code, then there's a power law for concurrent code. When Simon Peyton Jones was working at Microsoft Research on Software Transactional Memory, he prefaced practically every video/interview with this uncomfortable fact. Given the lack of traction, I can only assume that some of the corner cases of STM proved to be intractable, and my read on the domain is that borrow semantics are trying to arrive at a similar place by different avenues. I'm very interested to see 1) how far borrow semantics get, in the same way that type inference simplifies generics, and 2) what someone tries next, particularly if it involves synthesizing elements from different schools.

jerf 4y ago
The problem with STM is A: You can not retrofit it on to an existing language and B: The language you build to support it looks an awful lot like Haskell, particularly the careful separation between pure and IO code. And as of 2022, most programmers are not willing to program that way. I do a lot of concurrency stuff, and my go-to is one form or another of message passing. It isn't a miracle cure, but it turns the exponentially complicated issues with lock-based systems into polynomial ones, and that's at least something you have a prayer of managing. They compose better. I'm not sure I'd say they compose well, and someone may yet find an even better model, but they compose better. (STM doesn't seem to be that model. As the transactions inevitably get larger over time they start getting complicated.)

vitus 4y ago

> forgetting to synchronize at all, inconsistent locking At least for these two classes of categories, mutex usage at Google is broadly paired with compiler-enforced annotations to enforce that _all_ accesses to mutex-guarded member variables are done while holding the appropriate mutex. https://abseil.io/docs/cpp/guides/synchronization#thread-annotations https://abseil.io/docs/cpp/guides/synchronization#thread-ann... (While yes, it can also help with deadlock avoidance as well, that tends to be trickier to enforce across the board, especially if the mutexes in question belong to different objects. There's separate deadlock detection baked into Abseil that's used primarily in non-production builds.)