Hi Dean,
Thanks for your input.
I think a monitor would be less ideal here:
A monitor would introduce blocking in enqueuing operations.
The posters are (in this case) remotely injected threads (by another
process), and the processes injecting those threads are in
WaitForSingleObject() on
Hi Markus. OK, thanks for the explanation.
dl
On 3/3/2015 1:15 AM, Markus Gronlund wrote:
Hi Dean,
Thanks for your input.
I think a monitor would be less ideal here:
A monitor would introduce blocking in enqueuing operations.
The posters are (in this case) remotely injected threads (by
Couldn't you instead treat it like a monitor? Then it's OK if only the
first
notify wakes up the blocked thread, as long as that thread only blocks when
the queue is empty. In other words, when it wakes up, it should process all
the items in the queue before blocking again.
dl
On 3/2/2015
Markus,
Looks good for me. Excellent finding.
Variable
229 BOOL not_exceeding_semaphore_maximum_count =
is not used in production and it could lead to a compiler warning.
So it might be better to use guarantee instead of assert here.
-Dmitry
On 2015-03-02 15:34, Markus Gronlund wrote:
Hi Markus,
On 2.3.2015 13:34, Markus Gronlund wrote:
Greetings,
Kindly asking for reviews for the following changeset:
Bug: https://bugs.openjdk.java.net/browse/JDK-8073042
Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/
Looks reasonable.
Description:
The signaling
Greetings,
Kindly asking for reviews for the following changeset:
Bug: https://bugs.openjdk.java.net/browse/JDK-8073042
Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/
Description:
The signaling mechanism used to communicate about attaching operations under
Windows
