On Monday, 13 May 2013 at 21:04:23 UTC, Juan Manuel Cabo wrote:
There is one thing that should definitely added to the
documentation, and that is what happens when one issues a
notify while the thread hasn't yet called Condition.wait().
I can confirm that under Win32 calling notify() before wait()
internally signals the condition and then calling wait() returns
immediately and actually does not wait. This is the expected
behavior and is actually how Win32 events work.
On Tuesday, 14 May 2013 at 08:58:31 UTC, Dmitry Olshansky wrote:
Have to lock it otherwise you have a race condition on a
condition variable (wow!).
Ok, i'll lock it just in case. It also makes me feel my code is
more robust. This will do right?
...
synchronized(cond.mutex)
cond.notify();
...
My internal bool variable that affects the condition (the one
that decides if the consumer thread should wait) must be setable
at any moment by any thread so i leave it outside the lock. Also,
after setting this variable i immediately call notify() with
mutex unlocked. That's why it is working i think.
Doesn't prove anything, it could happen that you just miss a
notification, for instance. Another common case is that it so
happens that wait will (with luck) always happen before any of
notify and notifications come spaced out in time.
True, i guess my code work 100% as needed because of its
implementation, in my case it doesn't matter if i miss a
notification because the result of that notification gets
evaluated in the next loop inside a while, but still most
probably as you say wait() is always happening before a
notification.
A classic producer-consumer program must lock both calls, i do
understand that.
