On Tue, Nov 29, 2011 at 1:01 PM, Jed Brown <[email protected]> wrote:
On Tue, Nov 29, 2011 at 12:53, Dmitry Karpeev <[email protected]> wrote:
I understand that any solution requires serialization: atomic reads by the spinning loop would serialize on that read, while pthread_cond_wait requires mutex serialization. sigwait serializes since it clears the signal atomically. Ultimately, all three rely on atomicity of some sort, but mutexes apparently have higher overhead for it? At least the stackoverflow page that suggests the sigwait solution reports a 40x improvement over the pthread_cond_wait solution (admittedly, I don't know the details of the sigwait stuff).
I wouldn't consider that stackoverflow post to be authoritative, but there is a large body of literature on lock-free synchronization.
Could you point me to some of it?
Unless there is resource contention, spinning is always the lowest latency choice. All multi-threaded cores have some sort of pause instruction because it's necessary to make that design useful. For this purpose, we should just spin.
Note that with sequential consistency,
What do you mean by "sequential consistency"? If we did serialize the threads before waking them up?
you can also provide information about the next work unit when you activate a thread. For example, you can pass a function pointer.