[lwip-devel] lwip deadlock in tcpip_apimsg using FreeRtos ST Arm Port with lwip sockets

[M T]

I'm seeing a very strange deadlock when multiple FreeRtos threads access the same socket. For some reason, one of the tasks blocks when waiting for the apimsg->msg.conn->op_completed semaphore. I believe this semaphore is used to ensure that a message was processed by the lwip internals. Has anybody seen this issue?

I'm not an expert at the internals of lwip, but I tried to trace the problem down. Please let me know if my reasoning is not correct:
Essentially, any message that needs to go to the internals use the  sys_mbox_post function which enqueues the message into a queue. The receiver of the queue routes the message to the correct processing entity based on the message and signals the semaphore indicating that the message was processed. However, if you are using the socket API, the semaphore used is the socket semaphore (and is a binary semaphore not a counting one). So, when multiple tasks try to send a packet, there is a possibility that one of the tasks will starve because the receiver task has already given the semaphore once and will not do it for the second time (I'm not extremely sure about this statement).

I modified the tcpip_apimsg function to wait if a message is being processed and then post the message. This seems to have reduced (but not eliminated) the problem.

Please let me know if my reasoning makes sense and if you guys have seen a fix for this problem...

Thanks,
MT