You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@impala.apache.org by "Zoltán Borók-Nagy (JIRA)" <ji...@apache.org> on 2017/10/28 15:24:02 UTC

[jira] [Created] (IMPALA-6125) Fix the usage patterns of condition variables

Zoltán Borók-Nagy created IMPALA-6125:
-----------------------------------------

             Summary: Fix the usage patterns of condition variables
                 Key: IMPALA-6125
                 URL: https://issues.apache.org/jira/browse/IMPALA-6125
             Project: IMPALA
          Issue Type: Improvement
            Reporter: Zoltán Borók-Nagy
            Assignee: Zoltán Borók-Nagy
            Priority: Minor


We should keep ourselves to the following good practices when using a condition variable:
* favor notify_one over notify_all
* the mutex associated with a condition variable should have been released by the time calling notify_* on the condition variable
* favor impala::ConditionVariable over boost::condition_variable

There are exceptions to all of these rules:
Use notify_all when:
* Different threads waiting on different condition expressions
* The operations of the waiting threads differ
* Multiple threads are needed to do the job

Hold mutex during notify:
* when the call of notify_*() is in the middle of a complex critical section. Still, my guess is most of the time the code can be restructured to release the lock before calling notify.

boost::condition_variable:
* the boost thread library supports thread interruption, impala::ConditionVariable doesn't (this is why it has lower overhead). If you need thread interruption, use boost::condition_variable





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)