Implement condition variables on Windows on top of Event/SetEvent/ResetEvent.

Implement condition variables on Windows on top of Event/SetEvent/ResetEvent.

ConditionVariable is only available since Vista so to support XP
we need to implement this ourselves.

R=asiva@google.com,sgjesse@google.com
BUG=
TEST=

Committed: https://code.google.com/p/dart/source/detail?r=4126

[Søren Gjesse, 2012-02-08 15:32:58]

lgtm

https://chromiumcodereview.appspot.com/9361036/diff/1/runtime/platform/thread...
File runtime/platform/thread_win.cc (right):

https://chromiumcodereview.appspot.com/9361036/diff/1/runtime/platform/thread...
runtime/platform/thread_win.cc:217: EnterCriticalSection(&data_.waiters_cs_);
I am wondering whether we can get into a situation where resetting
data_.notify_all_event_ will be postponed for a long time if the waiting threads
gets signaled on the data_.notify_event_. Would it be better to have the
data_.notify_all_event_ be the first handle in the call to
WaitForMultipleObjects. Not sure whether it matters.

[siva, 2012-02-08 22:19:27]

Chrome seems to use a different approach for solving this.

Please see http://www.cs.wustl.edu/~schmidt/win32-cv-1.html
which describes some issues with the current implementation.

Chrome seems to keep a list of events and a thread coming into to wait grabs a
event and waits on it. The event seems to be put into a wait list. Notify picks
an event from the wait queue and does a SetEvent on it and broadcast picks all
the events in the wait queue and does a SetEvent on them.

Since we have a controlled view of threads in the dart system we could even go
to the extent of creating an Event for each thread created (would have to have
some special initialization for the main thread) and use this event for
waiting/signalling/broadcast etc. Instead of the per Monitor event queue that
Chrome uses.

[cshapiro, 2012-02-08 22:52:02]

An added benefit of using a per-thread semaphore is that the monitor waiting
code can be shared by all platform targets.

[Mads Ager (google), 2012-02-09 07:45:00]

Thanks for the comments. I will be happy to move to the list of events approach
to avoid the fairness/correctness issues with the approach in this changelist.

I'll be on vacation next week and I'm not sure I will have the time to update
this changelist before going on vacation. Siva, would you be OK with me
submitting this changelist and filing a new high priority bug on the
fairness/correctness issue? I will then fix that bug ASAP (either tomorrow or in
a week when I'm back from vacation.)

[cshapiro, 2012-02-09 09:18:20]

Another comment... you will likely want to avoid creating an explicit list of
events like the chrome condition variable.  That is required when the native
thread object cannot carry around its own synchronization primitive to wait on. 
Rather, you want to link together each thread object into separate queues for
waiting and entering a monitor.