Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Made sure detail::condition_variable can be safely destroyed #1488

Merged
merged 3 commits into from May 12, 2015

Conversation

hkaiser
Copy link
Member

@hkaiser hkaiser commented May 1, 2015

Made sure detail::condition_variable can be safely destroyed while its notify_one or notify_all are still executing. This fixes #1481

…s notify_one or notify_all are still executing
#include <hpx/hpx.hpp>
#include <hpx/hpx_main.hpp>
#include <hpx/include/local_lcos.hpp>
#include <hpx/util/lightweight_test.hpp>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test is called safely_destroy_cv but actually test for promise/future.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uhh, right. It still relies on the behavior of the condition_variable, though. Let's change the name of the test, though.

@K-ballo
Copy link
Member

K-ballo commented May 12, 2015

LGTM. Should be revisited in a future to see if the design can be improved and made safe.

hkaiser added a commit that referenced this pull request May 12, 2015
Made sure detail::condition_variable can be safely destroyed
@hkaiser hkaiser merged commit 56f549b into master May 12, 2015
@hkaiser hkaiser deleted the fixing_1481 branch May 12, 2015 20:04
K-ballo added a commit to K-ballo/hpx that referenced this pull request May 16, 2015
Since STEllAR-GROUP#1488, the semantics of locks used with detail::cv where changed in a way that is difficult to handle correctly with Lockables that do not represent ownership. To avoid this fragile scenario, detail::cv now only accepts `boost::unique_lock`s, which are known to be safe.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Sync primitives safe destruction
2 participants