In short: in case of two client threads requesting in same time from server, they may get each one the answer of the else and hence return kErpcStatus_ExpectedReply due to wrong sequence number
Deep dive to the scenario:
In case of simple client is used (not arbitrated), the function performClientRequest sends and receives without locking the mutex (but the receive itself and the send itself runs locked in the framed transport class).
That may lead to scenario of the following steps:
thread A sends request
context switch happens and thread B running and send request (may likely happen if B has higher priority and it tried to send request when A was in middle, and was blocked on the send lock till A will finish his send)
thread B enters receive and blocks/busy waiting to response
server get request A (as it was sent first) and responds to it
thread B get the respond to A and return kErpcStatus_ExpectedReply due to wrong sequence number and releasing the lock
Thread A get into recieve
server get request B (as it was sent first) and responds to it
thread A get the respond to B and return kErpcStatus_ExpectedReply due to wrong sequence number
It should be noted this is probably won't happen in arbitrated client where all client are assigning there sequence number and the arbitrator waking up the relevant thread according the sequence number.
To Reproduce
run two client threads with different priorities on long send/receive loops
Expected behavior
Each thread getting its response
Screenshots
Not applicable
Desktop (please complete the following information)
OS: linux
eRPC Version: 1.10.0
Steps you didn't forgot to do
[x] I checked if there is no related issue opened/closed.
[x] I checked that there doesn't exist opened PR which is solving this issue.
amgross
commented
5 days ago
Describe the bug
In short: in case of two client threads requesting in same time from server, they may get each one the answer of the else and hence return kErpcStatus_ExpectedReply due to wrong sequence number
Deep dive to the scenario: In case of simple client is used (not arbitrated), the function performClientRequest sends and receives without locking the mutex (but the receive itself and the send itself runs locked in the framed transport class).
That may lead to scenario of the following steps:
It should be noted this is probably won't happen in arbitrated client where all client are assigning there sequence number and the arbitrator waking up the relevant thread according the sequence number.
To Reproduce
run two client threads with different priorities on long send/receive loops
Expected behavior
Each thread getting its response
Screenshots
Not applicable
Desktop (please complete the following information)
Steps you didn't forgot to do
Additional context