Introduce a mutex owned by each port that protects its connections #283
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
The connection_mutex owned by the port's ConnectionManager was only protecting its internal list of connections. At least connections that involve shared buffers were subject to race conditions if multiple threads establish and disconnect connections concurrently. The new mutex is locked early inside the ConnFactory and inside ConnInputEndPoint and ConnInputEndPoint for the case port connection is disconnected from the remote end. InputPortInterface::connected() and OutputPortInterface::connected() are forwarding to their respective ChannelElement endpoints, where the test can be done in lock-free way. The ports_test has been updated to also cover errors during concurrent connection management. Signed-off-by: Johannes Meyer <johannes@intermodalics.eu>
2 tasks
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.
The
connection_mutexowned by the port'sConnectionManagerwas only protecting its internal list of connections, but not the whole process of creating new connections, data objects or buffers. At least connections that involve shared buffers (#114) were subject to race conditions if multiple threads establish and disconnect connections concurrently.The new port connection mutex is locked early inside the
ConnFactoryand insideConnInputEndPointandConnInputEndPointfor the case port connection is disconnected from the remote end.InputPortInterface::connected()andOutputPortInterface::connected()are forwarding to their respective ChannelElement endpoints, where the test can be done in lock-free way.The
ports_testhas been updated to also cover errors during concurrent connection management.Note that writing to and reading from ports with only lock-free connections (the default) is still expected to be a lock-free operation. Only adding or removing port connections involves locks (as it has been before for the mutex owned by the
ConnectionManager).