Skip to content

std::condition_variable::notify_one/all() should be called after unlocking mutex #1448

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

Merged
merged 4 commits into from
Dec 9, 2022
Merged

Conversation

jimmy-park
Copy link
Contributor

The notifying thread doesn't need to hold the lock because the notified thread may immediately block again in some implementations. (see description and example in cppreference)
There is another caveat about notifying while holding a lock, but I think it isn't relevant to current implementation of ThreadPool.

I also recommend the implementation of task system which presented in Sean Parent's talk.

@yhirose
Copy link
Owner

yhirose commented Dec 5, 2022

@jimmy-park thank you for the reply. Could you add at least one unit test case to verify your modification works? Then, I'll do code review. Thanks!

@jimmy-park
Copy link
Contributor Author

@yhirose I added a simple test which increases an atomic counter using TaskQueue . Since TaskQueue is only used in listen_internal(), I think it acts like a SPMC (single producer multiple consumer) queue and test code follows this behavior. I know this is an oversimplified example. Do we need more test cases for concurrency?

@yhirose
Copy link
Owner

yhirose commented Dec 5, 2022

@jimmy-park, the reason why I need the unit test is that I would like to reproduce the problem you mentioned above on my machine and confirm that your modification fixes it. Otherwise, there is no way for me to verify your fix is acceptable. :)

@jimmy-park
Copy link
Contributor Author

@yhirose Understood 😄

@yhirose
Copy link
Owner

yhirose commented Dec 9, 2022

@jimmy-park, I just tried to run TaskQueueTest.IncreaseAtomicInteger with the current httplib.h without your change, but it worked fine with no problem. How did you find the current implementation of TaskQueue has a problem?

@jimmy-park
Copy link
Contributor Author

@yhirose The unit test I added was a simple check of the basic functionality of TaskQueue. It works in current implementation because all waiting threads will wake up on TaskQueue::shutdown(). I think it maybe a performance issue in some platforms as cppreference says, not a functionality issue. It is hard to point out which platform has this issue, so I recommend to follow cppreference's example.

@yhirose yhirose merged commit 58cffd3 into yhirose:master Dec 9, 2022
@yhirose
Copy link
Owner

yhirose commented Dec 9, 2022

@jimmy-park, thanks for your replay. I read the cppreference and now understand what you were trying to do. Your change looks good to me, and I just merged it. Thanks a lot!

ExclusiveOrange pushed a commit to ExclusiveOrange/cpp-httplib-exor that referenced this pull request May 2, 2023
…cking mutex (yhirose#1448)

* Move next job in task queue rather than copy

* Notify waiting thread after unlocking mutex

* Add unit test for TaskQueue

* Don't use C++14 feature in test code
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants