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

Fix lock ordering issue in udp_channels #1876

Merged

Conversation

2 participants
@cryptocode
Copy link
Collaborator

commented Mar 30, 2019

The load-tester exposed this lock ordering bug:

IO thread 1:
: rpc::process -> TX WRITE LOCK -> ... -> udp::channels::size -> MUTEX LOCK

IO thread 2:
: ongoing_peer_store -> MUTEX LOCK -> TX WRITE LOCK

(load-tester still occasionally times out with the tool's defaults; reducing node count or increasing timeout helps, but there's no longer a deadlock)

@cryptocode cryptocode added the bug label Mar 30, 2019

@cryptocode cryptocode added this to the V19.0 milestone Mar 30, 2019

@cryptocode cryptocode self-assigned this Mar 30, 2019

@cryptocode cryptocode requested a review from wezrule Mar 30, 2019

@cryptocode cryptocode added this to CP3 (2019-04-10) in V19 Mar 30, 2019

@wezrule
Copy link
Collaborator

left a comment

As we know the number of endpoints ahead of time, you could reserve the memory up front.

@cryptocode cryptocode merged commit 232cb55 into nanocurrency:master Mar 30, 2019

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@cryptocode cryptocode deleted the cryptocode:fix/udp_channels-lock-ordering branch Mar 30, 2019

guilhermelawless added a commit to guilhermelawless/nano-node that referenced this pull request Apr 15, 2019

Fix lock ordering issue in udp_channels (nanocurrency#1876)
* Fix lock ordering issue udp channels

* Reserve space for endpoints
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.