You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From looking at the code I saw the following two things:
Could it be that the mutex of a command is locked in thread A when Cola2Session::sendTelegramAndListenForAnswer is called, and then unlocked in thread B (ASIO io service thread) when Cola2Session::processPacket is called when the answer is received? If this is the case, then this is undefined behavior.
Also what happens, when a command is sent, and no answer is received (because of some error). Is the mutex then never unlocked?
The text was updated successfully, but these errors were encountered:
Hi, thanks for spotting this. I think you are correct with the undefined behavior. It should not occur that the unlock will be triggered before the lock; however, you are correct that it's undefined behavior in the current version.
And for the second part, yes, it would lock permanently currently, so maybe a timeout would be beneficial.
From looking at the code I saw the following two things:
Could it be that the mutex of a command is locked in thread A when Cola2Session::sendTelegramAndListenForAnswer is called, and then unlocked in thread B (ASIO io service thread) when Cola2Session::processPacket is called when the answer is received? If this is the case, then this is undefined behavior.
Also what happens, when a command is sent, and no answer is received (because of some error). Is the mutex then never unlocked?
The text was updated successfully, but these errors were encountered: