[
https://issues.apache.org/jira/browse/CASSANDRA-9962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654957#comment-14654957
]
Benedict commented on CASSANDRA-9962:
-------------------------------------
bq. A semaphore would be an easier way to wait for the thread(s) to be
initialized?
Define easier :)
The main benefit of a {{Semaphore}} is that it does not busy spin; otherwise
spinning on an atomic counter is just as easy. However stylistically I'd have
no issue switching. The main benefit of busy spinning is it increases the
likelihood of interesting thread interleavings, which is useful for testing
this kind of functionality. Really, though, we should have a burn test, and I'm
kind of surprised we do not. I thought we used to. Really I would like to merge
[my concurrent utils|https://github.com/belliottsmith/bes-utils] with the tree,
or link them, as we've had a few bugs and behavioural issues that could have
been avoided with them, and they have pretty comprehensive burn tests,
including for its variant on {{WaitQueue}}.
bq. Maybe we should define a few constants in Util.java for how long to wait
for this kind of condition?
I'm not sure there's a universally good large constant, but I've introduced a
{{Util.joinThread()}} method with a 10s timeout. Which may be too large, but
will probably suffice for now.
bq. here is also no atomicity between signaling ready and getting into the wait
queue.
Sure there is. We signal only after we add ourselves to the queue.
> WaitQueueTest is flakey
> -----------------------
>
> Key: CASSANDRA-9962
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9962
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Priority: Minor
> Fix For: 3.x
>
>
> While the test is a little noddy, and superfluous, it shouldn't fail even
> vanishingly infrequently. [~aweisberg] has spotted it doing so, and I have
> also encountered it once, so I suspect that a change in hardware/OS may have
> made vanishingly unlikely just pretty unlikely, which is even less good.
> Right now it depends on {{Thread.start()}} completing before the new thread
> starts; this isn't guaranteed. This patch fixes that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
