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

Avoid lock pessimisation #1284

cryptocode opened this issue Oct 10, 2018 · 1 comment


3 participants
Copy link

commented Oct 10, 2018

Locks on a given mutex shouldn't cover notifications on conditional variables over the same mutex as it leads to pessimization.


One example is going from:

    std::lock_guard<std::mutex> lock (mutex);
    free.push_back (data_a);
    condition.notify_one ();


        std::lock_guard<std::mutex> lock (mutex);
        free.push_back (data_a);
    condition.notify_one ();

An alternative is to unlock instead of scoping.


This comment has been minimized.

Copy link

commented Dec 15, 2018

Added a pull request for this issue #1461. Tests are passing and everything looks normal.
Like mentioned in the pull request, some of the explicit locking would be unnecessary if we used std::atomic_bool on those flags instead.

This is something I want to add later unless someone has an issue with atomics in std.

@rkeene rkeene added this to the V18.0 milestone Dec 16, 2018

@zhyatt zhyatt added this to Unscheduled in V18 Dec 27, 2018

@zhyatt zhyatt moved this from Unscheduled to Unassigned in V18 Dec 27, 2018

@zhyatt zhyatt moved this from Unassigned to CP 0 in V18 Dec 28, 2018

@zhyatt zhyatt moved this from CP 0 to Unscheduled in V18 Dec 28, 2018

@cryptocode cryptocode moved this from Unscheduled to CP 0 in V18 Dec 29, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.