Fix CCheckQueue IsIdle (potential) race condition #9495
Conversation
| @@ -185,8 +182,7 @@ class CCheckQueueControl | |||
| { | |||
| // passed queue is supposed to be unused, or NULL | |||
| if (pqueue != NULL) { | |||
| bool isIdle = pqueue->IsIdle(); | |||
| assert(isIdle); | |||
| ENTER_CRITICAL_SECTION(pqueue->ControlMutex); | |||
There was a problem hiding this comment.
Can you do this as a unique_lock field inside CCheckQueueControl (so we don't need to rely on an explicit destructor to be correct)?
There was a problem hiding this comment.
Unfortunately this is the "easiest" way to take care of this given that we want debug order & the CMutex class has no default constructor/moveable semantics. Certainly can be fixed to RAII easily later.
There was a problem hiding this comment.
Understood. Let's improve that in a separate PR later.
src/checkqueue.h
Outdated
| if (pqueue != NULL) { | ||
| ENTER_CRITICAL_SECTION(pqueue->ControlMutex); | ||
| } | ||
| CCheckQueueControl<T>() = delete; |
There was a problem hiding this comment.
Nit: I think you can drop the <T>
JeremyRubin
force-pushed
the
checkqueue-control-lock
branch
from
2a58f73
to
020acd8
Compare
|
Squashed and addressed @ryanofsky's nit about template args in constructors. |
src/checkqueue.h
Outdated
| CCheckQueueControl& operator=(const CCheckQueueControl&) = delete; | ||
| explicit CCheckQueueControl(CCheckQueue<T> * const pqueueIn) : pqueue(pqueueIn), fDone(false) | ||
| { | ||
| // passed queue is supposed to be unused, or NULL |
There was a problem hiding this comment.
Oops -- somehow, my expandtab and tabstop=4 got unset.
JeremyRubin
force-pushed
the
checkqueue-control-lock
branch
from
020acd8
to
f5daff7
Compare
|
sorry for causing extra review -- pushed and squashed indention fix. |
| @@ -127,6 +127,9 @@ class CCheckQueue | |||
| } | |||
|
|
|||
| public: | |||
| //! Mutex to ensure only one concurrent CCheckQueueControl | |||
| boost::mutex ControlMutex; | |||
There was a problem hiding this comment.
Nit: Is there some coding standard for mutexes which makes you capitalize this ivar? If not, maybe controlMutex would be more consistent.
|
#9497 was merged, which included this. Closing. |
There's a small race condition in the CCheckQueue code which I don't think is currently an active issue, but future code might break.
IsIdle is not threadsafe. If two concurrent
CCheckqueueControls are made, they could simultaneously report being idle, and fail to panic.Furthermore, in the case a concurrent
CCheckqueueControlis made, most likely waiting until control is relinquished is the right behavior rather than failing an assert.