I’m not really familiar with you application, but in general it should not be required to have a mutex at all for bidirectional socket communication.
mike919192 - agreed. In this case, the lock is used to sequence accesses to the WebSocket client state, since either side can send a WebSocket-level close, as well as sequencing multiple writers - I didn’t consider it until now, but the reader-thread does respond to WebSocket ‘ping’ messages with ‘pong’ messages immediately on receipt.
RAc - that’s exactly what WebSockets do - provide asynchronous, full-duplex framing over TCP or TLS. Either side can send as long as there is buffering room. We’re playing a turn-based game over the WebSocket, as well as exchanging various data(who is online, game status, things like that).
How about a single task that does all the websocket I/O? The task itself can use all kinds of logic to prioritize reading and writing depending on conditions.
That may be the right solution. I’m hoping not to replace or rewrite the Espressif WebSocket client, which is where the reader-task comes from. It doesn’t currently have anything like a command-queue where other threads could send it write-requests.