https://bugs.winehq.org/show_bug.cgi?id=46099
--- Comment #22 from Greg Smith codedonewell@gmail.com --- (In reply to Zebediah Figura from comment #21)
(In reply to Fabian Maurer from comment #20)
We need to be able to very that, at the exact point that the thread is queued on select(), the value still matches the comparand.
What do you mean?
If we check that the value matches before queueing, we can get a race of the form:
thread A: checks value, still equal to comparand thread B: sets value thread B: perform wake thread A: queue self
We need to prevent such a wake from occurring between the time thread A checks the value for the last time, and the time it queues itself.
The Linux kernel manages this with futexes by locking the queue and then (effectively) atomically comparing the value and queueing the thread. We can't really use this approach, since we can't be reading process memory from the wineserver.
My idea was to split queueing and waiting into two separate operations for futexes, though now I'm wondering if perhaps a CS might be better here.
Thanks for looking at this. I am just too new to wine changes to be confident in the impacts of making the changes that I think are required. Looking at what is there, I failed to think of a way to do it without changing or at least copying the wineserver_select code - something that my experience tells me is almost always means I don't understand how it works well enough. I also think that CS may be a better path, but there seems to always be an opportunity for a race condition. I certainly have an even greater respect now for what pthread_cond_wait achieves!