Nanostack: release connect_semaphore only when it is pending #10462
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
michalpasztamobica
force-pushed
the
nanostack_semaphore_release_connecting
branch
from
1f211da
to
b7d460d
Compare
kjbracey
approved these changes
Apr 24, 2019
There was a problem hiding this comment.
Good example of why I hate semaphores so much. The counting is almost always a hindrance, not a help.
I'd be inclined to tear it all up and use a ConditionVariable instead, which would give better control of potentially complex conditions like this, but this will do.
Only release if the current _connect_status is CONNECTING. If the semaphore is released many times for each connect, then the next connect will not wait(), as it will be able to decrement the semaphore imediatelly.
michalpasztamobica
force-pushed
the
nanostack_semaphore_release_connecting
branch
from
b7d460d
to
2b26a62
Compare
SeppoTakalo
approved these changes
Apr 24, 2019
|
ci started |
Test run: SUCCESSSummary: 11 of 11 test jobs passed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
The rationale behind this PR is the following. It often happens that a Thread device gets local connectivity before the global connectivity. In such case the network handler is called twice and each time releases the _connect_semaphore. If the device disconnects and then connects again, the previously released (incremented) semaphore will be available for immediate decrementation and the connect will not really block.
This fixes failures in NETWORKINTERFACE_CONN_DISC_REPEAT test for Thread protocol.
I also noticed some detailed guidelines about when to consider a Thread device connected, but those are Thread-specific, and should not be implemented in general Nanostack network_handler. It made me wonder however if the semaphore should perhaps be released in the lower layer, so a Thread device unblocks at a different point than a LOWPAN device, perhaps?
@0xc0170 , does the CI for PRs run any Nanostack tests? I assumed not and hacked our CI to run this commit for me on multiple platforms to check that nothing gets broken, but I wonder if I should have relied on CI?
Pull request type
Reviewers
@SeppoTakalo
@KariHaapalehto
@VeijoPesonen