When a thread uses semaphores (concretely sema_wait_timed) messages are dropped from the message queue. This causes a thread acting on messages to lose events due to the use of a semaphore. Imagine a thread receiving events from [drivers, other threads, ...] and depending on the message it send a message using lwip. Since the current implementation of lwip relies on the sema_wait_timed method, messages are just dropped. This is a kind of non obvious behaviour and difficult to track. I guess it's also a non desired behaviour.

Has anyone dealt with a similar situation already?

One option would be to modify the sema API to avoid this case. However, I rather suggest the following change in the msg API in order to be more consistent with the handling of messages.

• Add msg_receive_type(msg_t *m, uint16_t mask) and similar msg_try_receive_type(...) where the receiving thread can specify a mask for the messages it is interested in. The other messages are not dropped and keep the same position in the queue.
• Tackle combine all msg types #1749

This would allow a much finer control of the communication between threads and a starting point to define a reserved range to be used by the system and libraries as in #1749.

If you agree, I'd prepare a PR for the first point.