Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
If you need really good synchronization primitives while Glibc is fixing things then I've had a lot of success with *NSYNC https://github.com/google/nsync which is what Cosmopolitan Libc uses to implement pthread_cond_t.
I wrote my own FOSS signals/events library in C++ [0] and in rust [1] (atop of parking lot as a futex shoe-in) and I disagree. This has nothing to do with the language and everything to do with the semantics of the locks. Writing concurrency primitives is HARD and the more functionality your API exposes, the more room there is for nuanced bugs in how everything interplays with everything else.
[0]: https://github.com/neosmart/pevents
[1]: https://github.com/neosmart/rsevents
I wrote my own FOSS signals/events library in C++ [0] and in rust [1] (atop of parking lot as a futex shoe-in) and I disagree. This has nothing to do with the language and everything to do with the semantics of the locks. Writing concurrency primitives is HARD and the more functionality your API exposes, the more room there is for nuanced bugs in how everything interplays with everything else.
[0]: https://github.com/neosmart/pevents
[1]: https://github.com/neosmart/rsevents
Rust’s synchronization types are built on the semantics of shared objects, with the synchronization object owning the data access to which is channeled exclusively via the synchronization type.
Events and signals aren’t intended to be used off you’re trying to share ownership of memory or data - you should use the std types in that case. They’re for signaling between threads or for building your own synchronization objects atop of. For example, an auto reset event can be used in lieu of a one-bit channel (sort of like Mpmc<()>) and manual reset events can be used to implement the same in broadcast mode, much more efficiently than the channel crates. A common usage is to block until an event is available or a shutdown has been requested - in lieu of manually polling an AtomicBool and aborting if it is true, making your code more responsive (no delay between polls) and more efficient (no repeated polling, no busy waits, etc). They can be used to signal state transitions or readiness, which doesn’t have anything to “own”, for example, the rsevents-extra crate [0] implements a countdown event (event becomes available when n outstanding tasks have finished in parallel threads) or a semaphore (restricting concurrency to a region of code, not limiting access to a variable or object).
[0]: https://github.com/neosmart/rsevents-extra
macOS uses its own pthreads implementation: https://github.com/apple-oss-distributions/libpthread
They don't need a patch from me, they need the will to DTRT and at least revert the commit [0] that broke things. Glibc has had a functioning pthread_cond_t that at least didn't randomly deadlock, this isn't some impossible to implement feature.
That commit claims to fix ordering guarantees required by the spec, but in doing so has introduced real deadlock bugs.
The linked discussion at [1] is telling. It seems glibc's nptl is prioritizing playing games with optimizations over correctness, even before [0] landed.
To suggest all that's required is someone showing up with a patch is to completely ignore the fact that there's zero shortage of correct pthread_cond_t implementations all over the place. This is a maintenance failure, not a lack of code.
[0] https://github.com/bminor/glibc/commit/ed19993b5b0d05d62cc88...
[1] https://austingroupbugs.net/view.php?id=609
Related posts
- Implementing truly safe semaphores in rust, and the cost we pay for safety
- Learning Async Rust with Too Many Web Servers
- Implementing truly safe semaphores in rust
- Hyperbridge: Fast multi-producer, multi-consumer unbounded channel in Rust
- Show HN: Rust crate providing a unified high-level API for WireGuard protocol