You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 5013 Reporter: omion Assigned to:@xavierleroy Status: closed (set by @xavierleroy on 2011-05-29T10:19:33Z) Resolution: fixed Priority: normal Severity: major Version: 3.11.1 Fixed in version: 3.12.0+dev Category: ~DO NOT USE (was: OCaml general) Monitored by:@ygrek
Bug description
If two threads are waiting on a condition, Condition.broadcast should wake both of them up. However, if the first thread to be awoken waits on the same condition again it may be woken up again instead of the other thread.
I marked reproducibility as random since it depends on threads, but it happens about 50% of the time.
Linux and bytecode-Windows seem to be immune from this problem.
Additional information
The attached code can display the problem. Each line of the output begins with the thread which is printing it. two threads "t1" and "t2" wait on condition "c". The main thread then broadcasts the condition, which SHOULD wake up both threads eventually. On Linux this program always outputs:
1: waiting first
2: waiting first
0: BROADCAST
2: going from broadcast; waiting second
1: going from broadcast; waiting second
indicating that both threads woke up. On Windows the program may return:
1: waiting first
2: waiting first
0: BROADCAST
1: going from broadcast; waiting second
2: going from broadcast; waiting second
which is also correct (the threads were woken up in the opposite order as on Linux, but that doesn't matter). However Windows may also return the following:
1: waiting first
2: waiting first
0: BROADCAST
2: going from broadcast; waiting second
2: going from broadcast a second time
basically the broadcast woke up thread #2 TWICE, without waking up thread #1 at all. If this were a real program which was waiting on thread #1 to continue it would deadlock.
The Win32 implementation of condition variables was indeed incorrect w.r.t. Condition.broadcast. Reimplemented condition variables under Win32 in a way that should conform to POSIX semantics. Will go in 3.12.0.
Original bug ID: 5013
Reporter: omion
Assigned to: @xavierleroy
Status: closed (set by @xavierleroy on 2011-05-29T10:19:33Z)
Resolution: fixed
Priority: normal
Severity: major
Version: 3.11.1
Fixed in version: 3.12.0+dev
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @ygrek
Bug description
If two threads are waiting on a condition, Condition.broadcast should wake both of them up. However, if the first thread to be awoken waits on the same condition again it may be woken up again instead of the other thread.
I marked reproducibility as random since it depends on threads, but it happens about 50% of the time.
Linux and bytecode-Windows seem to be immune from this problem.
Additional information
The attached code can display the problem. Each line of the output begins with the thread which is printing it. two threads "t1" and "t2" wait on condition "c". The main thread then broadcasts the condition, which SHOULD wake up both threads eventually. On Linux this program always outputs:
1: waiting first
2: waiting first
0: BROADCAST
2: going from broadcast; waiting second
1: going from broadcast; waiting second
indicating that both threads woke up. On Windows the program may return:
1: waiting first
2: waiting first
0: BROADCAST
1: going from broadcast; waiting second
2: going from broadcast; waiting second
which is also correct (the threads were woken up in the opposite order as on Linux, but that doesn't matter). However Windows may also return the following:
1: waiting first
2: waiting first
0: BROADCAST
2: going from broadcast; waiting second
2: going from broadcast a second time
basically the broadcast woke up thread #2 TWICE, without waking up thread #1 at all. If this were a real program which was waiting on thread #1 to continue it would deadlock.
File attachments
The text was updated successfully, but these errors were encountered: