[
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)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
