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

udp_buffer could hang #1491

Closed
starrynightglider opened this issue Dec 21, 2018 · 5 comments

Comments

Projects
4 participants
@starrynightglider
Copy link

commented Dec 21, 2018

Description of bug:
in udp_buffer, full and free share the same condition_variable. In one scenario, when most of the thread are waiting, excepting one that is going to release() udp_buffer, it is possible that release() will wake up the thread that is waiting in full queue. The thread wakes up and checks the full queue, since it's empty, so it wait again. Dead lock at the end.

This issue can be easily reproduce by changing the TEST below.

Steps to reproduce the issue:
1.
TEST (udp_buffer, many_buffers_multithreaded)
{
rai::stat stats;
rai::udp_buffer buffer (stats, 512, 16); --> change 16 to 4 or 2.

@slowaways

This comment was marked as resolved.

Copy link

commented Dec 21, 2018

WTF? Close this Issue! Empty issue!

@starrynightglider

This comment was marked as outdated.

Copy link
Author

commented Dec 21, 2018

Strange. I posted, but the description but was gone.
I reposted it below.

Description of bug:
in udp_buffer, full and free share the same condition_variable. In one scenario, when most of the thread are waiting, excepting one that is going to release() udp_buffer, it is possible that release() will wake up the thread that is waiting in full queue. The thread wakes up and checks the full queue, since it's empty, so it wait again. Dead lock at the end.

This issue can be easily reproduce by changing the TEST below.

Steps to reproduce the issue:
1.
TEST (udp_buffer, many_buffers_multithreaded)
{
rai::stat stats;
rai::udp_buffer buffer (stats, 512, 16); --> change 16 to 4 or 2.

@slowaways

This comment was marked as resolved.

Copy link

commented Dec 21, 2018

@starrynightglider Edit your issue. Don't comment.

@clemahieu

This comment has been minimized.

Copy link
Collaborator

commented Dec 21, 2018

Makes sense. It doesn't seem like this would deadlock but would stall processing until subsequent buffers came in and eventually the correct thread picked it up.

It seems the fix is to notify_all instead of notify_one. Does that sound like it fixes it?

@rkeene rkeene added the bug label Dec 21, 2018

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

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

@rkeene

This comment has been minimized.

Copy link
Contributor

commented Jan 3, 2019

This should be as part of V18.0's release, let us know if this appears to occur again.

@rkeene rkeene closed this Jan 3, 2019

@zhyatt zhyatt moved this from Unscheduled to CP 0 in V18 Jan 4, 2019

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.