Il 16/07/2012 16:09, Jan Kiszka ha scritto: > On 2012-07-16 16:03, Paolo Bonzini wrote: >> Il 16/07/2012 15:53, Jan Kiszka ha scritto: >>>>> >>>>> qemu_cond_wait only uses WaitForSingleObject with INFINITE timeout, and >>>>> the algorithm relies on that. >>> I see. But this doesn't look complex awfully. Just move the waker >>> signaling from within cond_wait under the mutex as well, maybe add >>> another flag if there is really someone waiting, and that's it. The >>> costs should be hard to measure, even in line of code. >> >> There is still a race after WaitForSingleObject times out. You need to >> catch the mutex before decreasing the number of waiters, and during that >> window somebody can broadcast the condition variable. > > ...and that's why you check what needs to be done to handle this race > after grabbing the mutex. IOW, replicate the state information that the > Windows semaphore contains into the emulated condition variable object.
It is already there (cv->waiters), but it is accessed atomically. To do what you suggest I would need to add a mutex. >> I'm not saying it's impossible, just that it's hard and I dislike >> qemu_cond_timedwait as much as you dislike semaphores. :) > > As you cannot eliminate our use cases for condition variables, let's > focus on the existing synchronization patterns instead of introducing > new ones + new mechanisms. I'm not introducing <fancy new primitive of the day>... semaphores have the advantage of having better support under Windows (at least older versions; Microsoft saw the light starting with Vista---yes I know the oxymoron---and added condvars). Paolo
