I believe I made it clear enough that this scenario only applies under the assumption of strictly sequential client requests.
Your use case is fairly straightforward to handle: In the middle state of the fsm outlined above (read request-gather results-write results), each worker thread knows which ADC is to be addressed and can thus put request relevant data on one of several queues (one queue per ADC, for example), passing identification data such as task id or a handle to a return queue, then blocks to wait for the corresponding ADC thread: Each ADC is being served by a thread that runs its own fsm, eg “remove request from its queue, serve request, pass result to the back queue passed in”.
it depends on whether you need to pass data back to the worker task or not as task notifications have no payload. But since tbe workers need to send some kind of result from the adc upstream to the client, I would think that some payload would need to be passed back which implies q queue.
since on a single ADC there is no concurrent request i though to have a global struct containing the response, the worker know which ADC also at which global data to look.
Or is this bad idea and should avoid to use a global variable for this?
Do this only if you are absolutely sure that the one to maintain your code is NOT as serial killer OR does not know your address. Concurrency and global variables are natural enemies. Miss one transaction for whatever reason and your results go to the wrong worker. This is the kind of stuff that can cost you weeks of tedious debugging. When thinking concurrency, think encapsulation.
I must admit that I have never heard of a “shutdown SHUT_WR (EOF) to notify server the request is complete”.
Researching a little bit, as i understand, is SHUT_WR not a good way to indicate EOF and half open connections cause only problems.
So even if FreeRTOS is lacking this feature, no interest from my side.