4 ms·
If you want easier concurrency, don't use mutexes, they're a bad pattern. It's well-established that the safe way to do concurrency is to use channels.
by mgaunard 4y ago
If you want easier concurrency, don't use mutexes, they're a bad pattern.
It's well-established that the safe way to do concurrency is to use channels.
- jstx1 4y agoWhat's the problem with mutexes?
- mgaunard 4y agoIf you have to ask, I suppose you shouldn't touch anything that involves concurrent or parallel execution.
- paulmd 4y agomutexes are inherently single-threaded code, it's exclusive. It's a point where all of your threads have to serialize and run one-at-a-time to perform a certain operation. additionally, common implementations often have bad behavior as the number of threads increases. spinlocks don't work well if you have 32 threads trying to take the same lock, they can consume quite a lot of CPU time just trying to take the lock. they don't work at all if you have thousands of threads (which is a situation that occurs regularly in GPGPU programming!). you can of course increase the number of locks but that's basically what SQL/RDBMS does with row locks - and now you have the problem of deadlock too. obviously it all depends on specifics - how many threads doing how much work on their own, compared to how many locks they're trying to take. it's not that they are inherently bad, they are in fact one of the basic primitives in concurrent programming really. they just don't really scale well with increased concurrency. unfortunately, the deeper solutions involve restructuring your program and your data processing (or the data itself) to expose higher levels of concurrency and less interdependency, which is its own can of worms.
- tlb 4y agoThat can work well for many programs, but no one has succeeded in writing a multithreaded kernel that way.
- gpderetta 4y agoI think that DragonflyBSD makes good use of message passing. But sometimes a mutex in the slow path is indeed the easiest solution.
- mgaunard 4y agoThere are no mutexes in any of the major kernels. Mutexes are by definition a userland construct.
- preseinger 4y ago> There are no mutexes in any of the major kernels https://docs.kernel.org/locking/mutex-design.html#when-to-use-mutexes https://docs.kernel.org/locking/mutex-design.html#when-to-us... > Unless [specific conditions] ... always prefer [mutexes] to any other locking primitive.
- mgaunard 4y agoI wouldn't call those mutexes myself, but fair enough, I suppose if linux uses this terminology, then that's what people would call it. But this sort of pattern isn't valid everywhere in a kernel. For example things handling interrupts etc wouldn't be able to use it. Also for performance reason you probably don't want to use that for synchronization for anything performance-critical, where you'd try to use something like RCU instead. Probably mostly convenient for initial setup.
- jstimpfle 4y agoChannels are a good abstraction for message passing and high-level requests in general, which happen a lot in web services for example. But there are other domains (like kernels) and there is not one way to do concurrency. If you need low-latency and small-scope data structure access, you can't afford to synchronize with another worker and have the request processed in a different context. Fine-grained locking (or potentially lock-free concurrency) is much faster here.
- samsquire 4y agoA mutex allows you to move potentially infinite amount of memory in one locked operation in constant time between threads. Channels imply immutable data structures so you're copying data into buffers and then synchronizing to send it. BEAM actually copies the data between processes (lightweight threads) heaps. I don't think it's always the case that channels are superior to mutexes in every case. I personally try write and understand lockfree algorithms and I've tried avoiding mutexes but I'm not using channels but things similar to left-right concurrency control.
- gpderetta 4y agoI'm not going to argue for mutex vs channel, but channels don't require immutable data and copying. You can forward unique_ptrs through channels and pass ownership for example, or you can forward async operations to perform remotely instead.
- mgaunard 4y agoYou can hand off data with channels without any copy. That you think mutexes work in constant time is funny. How long it takes to enter a mutual exclusion section is entirely non-deterministic and unbounded.
- samsquire 4y agoOnce the mutex is acquired, you can move any amount of data with a pointer. This is what I meant.
- mgaunard 4y agoWhile the mutex is held, everybody else that is in contention is waiting, possibly forever. It's a terrible paradigm not suitable for any serious systems programming, especially if you have any sort of real-time requirements.
- preseinger 4y agomutexes are a primitive that guarantee access to a resource is synchronized, and only one actor is accessing it at a time this necessarily requires actors in contention to wait, possibly forever it is a fundamental paradigm that is used extensively throughout every kind of programming, even in real-time systems
- preseinger 4y agochannels almost always use mutexes internally