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)