> ... which can be used only in-process, not between processess.
You can use them between processes if you use shared memory.
This is useful in realtime or any other low latency applications where one reader or writer cannot be blocked for more than a couple of hundred microseconds.
It is basically reimplementing the semaphore but it is controlled by the application. There are no system calls, no threads being suspended. Instead of the busy while loop it might be possible to use a fixed count of iterations or a specific timeout value.
Thanks, I completely forgot about using shared memory between processes. Lately I used exclusively sockets, as it provides a portable solution between languages and platforms. But you are right, it is not suitable for realtime or low latency applications.
Still I think the implementation in the article is bad, and you should avoid using it in production, because it uses too much busy waits and there is no error handling.
And if one don't use shared memory, just threads (as in the example code) you gain nothing from this solution. You'd better use a simple lock-based implementation, or if you need low latency a correct lock-free or even better, a wait-free queue.
You can use them between processes if you use shared memory.
This is useful in realtime or any other low latency applications where one reader or writer cannot be blocked for more than a couple of hundred microseconds.
It is basically reimplementing the semaphore but it is controlled by the application. There are no system calls, no threads being suspended. Instead of the busy while loop it might be possible to use a fixed count of iterations or a specific timeout value.
This is useful but in a very narrow context.