[QUESTION] FramedTransport m_sendLock

[djmuhlestein]

For my application I wanted to extend FramedTransport for a custom UART transport. In the Underlying send/receive, I think use the uart hardware similar to the way the uart zephyr transport works. I noticed that m_sendLock is not used in FramedTransport though. The zephyr port doesn't use it either. The only other two classes that do use it are the MUTransport and MBoxTransport but those classes extend Transport directly and have their own m_sendLock.

So, is this an error in FramedTransport? Should I simply Lock m_sendLock in my underlyingSend function or should FramedTransport be patched to correct this. My underlying uart hw is definitely not thread safe.

[github-actions]

Hi eRPC user. Thank you for your interest and welcome. We hope you will enjoy this framework well.

[amgross]

Hi @djmuhlestein , sorry for the delay.
The m_sendLock is not in use currently in framed transport because it calls to underlying send just once, and there is an assumption that the underlying send protects itself in case of two threads access it in same time.
You can see that m_receiveLock is in use because it calls underlying receive two time so need to ensure no other thread calls underlying send in middle.
In case your underlying send is not thread safe I suggest you to protect it in this level.

It may be noticed that in simple client there is issue #439 and for arbitrated client there is