Nano-node: udp_buffer could hang

[starrynightglider]

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]

WTF? Close this Issue! Empty issue!

[starrynightglider]

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]

@starrynightglider Edit your issue. Don't comment.

[clemahieu]

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]

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