4 ms·

It's not that bad. We just don't have the equivalent of GC for multi-threading yet, so the advice necessarily needs to be "just remember to take and release lo

by mrkeen 2y ago

It's not that bad. We just don't have the equivalent of GC for multi-threading yet, so the advice necessarily needs to be "just remember to take and release locks" (same as remembering to malloc and free). Hopefully someone will invent something like STM [1] in the distant year of 2007 or so [2]. It has actual thread-safe data structures. Not just the current choice between wrong-answer-if-you-dont-lock and insane-crashing-if-you-dont-lock. [1] https://www.adit.io/posts/2013-05-15-Locks,-Actors,-And-STM-In-Pictures.html https://www.adit.io/posts/2013-05-15-Locks,-Actors,-And-STM-... [2] https://youtu.be/4caDLTfSa2Q?feature=shared https://youtu.be/4caDLTfSa2Q?feature=shared

LegionMammal978 2y ago
Rust takes pride in its 'fearless concurrency' (strict compile-time checks to ensure that locks or similar constructs are used for cross-thread data, alongside the usual channels and whatnot), while Go takes pride in its use of channels and goroutines for most tasks. Not everything is like the C/C++/C#/Java situation where synchronization constructs are divorced from the data they're responsible for.
- neonsunset 2y ago
  Synchronization primitives in Go are just as divorced as elsewhere, sometimes even more so - it does have channels, but Goroutines cannot yield a value, forcing you to employ a separate storage location together with WaitGroup/Mutex/RWMutex (which, unlike Rust's RWLock, is separate too, although C# lets you model it to an extent). This results in community developing libraries like https://github.com/sourcegraph/conc https://github.com/sourcegraph/conc which attempt to replicate Rust's Futures / C#'s Tasks.
  - jpc0 2y ago
    Writing to a channel of size 1 feels a lot like a yeild to me, you can even do it in a loop. A task is an abstraction over those primatives in any language. To my knowledge TBB task graph abstract over a threadpool using exactly that concept. From what I've seen swift is the only language that properly handles concurrency. I'm taking another crack at rust but the fact that everyone uses tokio for anything parallel makes me feel like the language doesn't have great support for concurrency, it just has decent typing which isn't a surpise to anyone.
- ratorx 2y ago
  For C++, abseil’s thread annotations are quite nice for getting closer to the Rust style of locking. Of course, the Rust style is still much easier to understand and less manual.
- gf000 2y ago
  None of them solve the problems associated with the general category of race conditions. You can trivially create live/dead locks with channel/message-passing, and rust only prevents data races, though ownership is definitely a step in the right direction. (Well, go is not even memory safe under data races!) Also, Java is one of the languages where you can just add `synchronized` as part of the method signature, and while this definitely doesn't solve the problem, I don't think "divorced from the data" is accurate.
  - mrkeen 2y ago
    Re: 'synchronized' and data. It is a good distinction to make because sync does indeed lock control, not data. With ACID transactions or STM, an atomic section will run as-if-sequentially, full stop, since the data is locked. With Java sync, you get 'no other thread is in these lines of code' and you have to hope that's enough for the system to run as-if-sequentially.
    - gf000 2y ago
      I think it's an interesting distinction, but it's sort of OOP's main thing to encapsulate the local (possibly mutable) state, so that using an object externally will leave the inner state correct. I think the primary issue here is that synchronized should be the default case, with optionally lifting that very strict restriction for multi-threaded access. Nonetheless, objects with methods that would do STM on their inner state would be a pretty cool design.
- mrkeen 2y ago
  I'd love to get some examples of Rust's best-practice shared-mutable-state code. So far when I ask around here I get answers equivalent to "Rust guarantees that you aren't doing that."
DylanSp 2y ago
It's not a perfect situation, but C# has some dedicated collection classes for concurrent use - https://learn.microsoft.com/en-us/dotnet/api/system.collections.concurrent?view=net-9.0 https://learn.microsoft.com/en-us/dotnet/api/system.collecti.... There's still some footguns possible, but knowing "I should use these collections instead of the regular versions" is less error-prone than needing to take/release locks at every single use site.
- sunshowers 2y ago
  Concurrent maps are generally worse in terms of being able to understand the system than either non-concurrent maps guarded by a lock, or a channel/actor model with single ownership. Data-parallel algorithms should also generally use map-reduce rather than writing into the same map concurrently. I've written highly concurrent software with bog-standard hash maps plus channels. There are so many advantages to this style, such as events being linearized (and thus being easy to test against, log, etc).
stouset 2y ago
> "just remember to take and release locks" If only it were so easy.
sunshowers 2y ago
STM is not going to ever be a production thing outside of purely functional languages.
- saagarjha 2y ago
  That’s what everyone thought about affine types, too.
  - sunshowers 2y ago
    True! I've been following STM and HTM research work for a while, and it all seems quite niche unless all side effects are captured (which is something purely functional languages can do). There isn't a real path to scalability I think, which there was with affine types. Optimistic concurrency in general is a useful design pattern in many cases, though.

by mrkeen 2y ago

LegionMammal978 2y ago

Rust takes pride in its 'fearless concurrency' (strict compile-time checks to ensure that locks or similar constructs are used for cross-thread data, alongside the usual channels and whatnot), while Go takes pride in its use of channels and goroutines for most tasks. Not everything is like the C/C++/C#/Java situation where synchronization constructs are divorced from the data they're responsible for.

neonsunset 2y ago
Synchronization primitives in Go are just as divorced as elsewhere, sometimes even more so - it does have channels, but Goroutines cannot yield a value, forcing you to employ a separate storage location together with WaitGroup/Mutex/RWMutex (which, unlike Rust's RWLock, is separate too, although C# lets you model it to an extent). This results in community developing libraries like https://github.com/sourcegraph/conc https://github.com/sourcegraph/conc which attempt to replicate Rust's Futures / C#'s Tasks.
- jpc0 2y ago
  Writing to a channel of size 1 feels a lot like a yeild to me, you can even do it in a loop. A task is an abstraction over those primatives in any language. To my knowledge TBB task graph abstract over a threadpool using exactly that concept. From what I've seen swift is the only language that properly handles concurrency. I'm taking another crack at rust but the fact that everyone uses tokio for anything parallel makes me feel like the language doesn't have great support for concurrency, it just has decent typing which isn't a surpise to anyone.
ratorx 2y ago
For C++, abseil’s thread annotations are quite nice for getting closer to the Rust style of locking. Of course, the Rust style is still much easier to understand and less manual.
gf000 2y ago
None of them solve the problems associated with the general category of race conditions. You can trivially create live/dead locks with channel/message-passing, and rust only prevents data races, though ownership is definitely a step in the right direction. (Well, go is not even memory safe under data races!) Also, Java is one of the languages where you can just add `synchronized` as part of the method signature, and while this definitely doesn't solve the problem, I don't think "divorced from the data" is accurate.
- mrkeen 2y ago
  Re: 'synchronized' and data. It is a good distinction to make because sync does indeed lock control, not data. With ACID transactions or STM, an atomic section will run as-if-sequentially, full stop, since the data is locked. With Java sync, you get 'no other thread is in these lines of code' and you have to hope that's enough for the system to run as-if-sequentially.
  - gf000 2y ago
    I think it's an interesting distinction, but it's sort of OOP's main thing to encapsulate the local (possibly mutable) state, so that using an object externally will leave the inner state correct. I think the primary issue here is that synchronized should be the default case, with optionally lifting that very strict restriction for multi-threaded access. Nonetheless, objects with methods that would do STM on their inner state would be a pretty cool design.
mrkeen 2y ago
I'd love to get some examples of Rust's best-practice shared-mutable-state code. So far when I ask around here I get answers equivalent to "Rust guarantees that you aren't doing that."

DylanSp 2y ago

It's not a perfect situation, but C# has some dedicated collection classes for concurrent use - https://learn.microsoft.com/en-us/dotnet/api/system.collections.concurrent?view=net-9.0 https://learn.microsoft.com/en-us/dotnet/api/system.collecti.... There's still some footguns possible, but knowing "I should use these collections instead of the regular versions" is less error-prone than needing to take/release locks at every single use site.

sunshowers 2y ago
Concurrent maps are generally worse in terms of being able to understand the system than either non-concurrent maps guarded by a lock, or a channel/actor model with single ownership. Data-parallel algorithms should also generally use map-reduce rather than writing into the same map concurrently. I've written highly concurrent software with bog-standard hash maps plus channels. There are so many advantages to this style, such as events being linearized (and thus being easy to test against, log, etc).

stouset 2y ago

> "just remember to take and release locks" If only it were so easy.

sunshowers 2y ago

STM is not going to ever be a production thing outside of purely functional languages.

saagarjha 2y ago
That’s what everyone thought about affine types, too.
- sunshowers 2y ago
  True! I've been following STM and HTM research work for a while, and it all seems quite niche unless all side effects are captured (which is something purely functional languages can do). There isn't a real path to scalability I think, which there was with affine types. Optimistic concurrency in general is a useful design pattern in many cases, though.