My previous post was a little short because I didn't have the time, so
I'll try again:
What you wrote is correct, except the fix is not that easy: Making the
semaphore a counting one would not help much, as you couldn't tell which
OP has completed when the semaphore is signaled. The solution would be
for each task to access the socket to have an own semaphore if we didn't
want to create a new semaphore for each call. So I'm afraid this won't
be that easy to fix.
However, I don't think you want to have multiple tasks reading or
multiple tasks writing at the same time: the thing most users asking
this question is to have one thread reading while another thread writes
(aka. full-duplex).
This could be easier to solve if we had one semaphore for read actions
and one for write actions. Still I have to disappoint you about a
planned fix for this. The current position of lwIP is just 'not
supported'! :-(
Simon
M T wrote:
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
------------------------------------------------------------------------
_______________________________________________
lwip-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-devel
_______________________________________________
lwip-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-devel