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 2021/01/04 09:42:00 UTC
[jira] [Resolved] (IMPALA-6125) Fix the usage patterns of condition
variables
[ https://issues.apache.org/jira/browse/IMPALA-6125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Zoltán Borók-Nagy resolved IMPALA-6125.
---------------------------------------
Resolution: Fixed
> Fix the usage patterns of condition variables
> ---------------------------------------------
>
> Key: IMPALA-6125
> URL: https://issues.apache.org/jira/browse/IMPALA-6125
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
> 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.
> * if there can be ownership issues, like in util/promise.h
> 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
(v8.3.4#803005)