3 ms·
It depends on what you're doing. For real-time applications you simply cannot use locks in a real-time thread, because there is no guarantee that you will unloc
by necubi 6y ago
It depends on what you're doing. For real-time applications you simply cannot use locks in a real-time thread, because there is no guarantee that you will unlock within your deadline. This is common in audio programming, where missing your deadline causes glitches in the audio stream.
It's definitely niche, but when you need them, you really need them.
- arakageeta 6y agoThat's not strictly true. There are dozens of real-time sleep-based locking protocols that support bounds on worst-case blocking time. Now, even if you have a suitable protocol available to you, your deadlines may be so tight that you can't afford the overhead of context switching. Then yes, you may need a lock-free or wait-free synchronization mechanism.
- necubi 6y agoI'm not sure if we're disagreeing here, but in the context of this article "a lock" is a kernel lock. What that implies will obviously depend on your kernel, but in Linux it means your thread may wait for an unbounded amount of time.