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

[Jonathan Larmour]

Alain M. wrote:
> Hi Simon,
> 
> address@hidden escreveu:
>> 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.
> 
> I am new to lwip, but from what I could understand so far, I believe
> that an intermediate solution would be fine for most cases: as the
> socket sends to netcomm, it could be done by a mailbox from the OS, in
> case of FreeRTOS it would be a QUEUE. This is thread safe as it is
> implemented by the OS.

But that breaks the API - the application is permitted to free the data
after the write() function is returned, so you can't have it still sitting
in a queue (and if you didn't free it immediately, how would you know when
you could). There's also the question of returning appropriate error codes
when the function returns. Which brings us back to the problem of trying to
work out which thread to wake up if there is more than one. The sys_arch
API doesn't have the right primitives for that, and once you start adding
primitives we start to get the problem that not everyone's OS supports
those primitives (e.g. peeking into the head entry of an mbox without
removing it).

Unless you're assuming that all data always has to be copied in its
entirety every time it enters the stack. I don't think that would be good.
Or dynamically creating new semaphores every time. I don't think that would
be very efficient either.

I do have one different idea of how to make it fit into the existing APIs,
but it would require a hard limit on the number of threads which can block
in lwIP simultaneously - essentially have a pool of semaphores, one per
thread which needs to block. When a write is made, an unused semaphore is
allocated to it, which it waits on. The semaphore address (or possibly the
array index of the semaphore, but address seems more future-proof) is put
into the message sent to the tcpip thread. When the write completes in the
stack, it then has a specific semaphore which can be woken up. When woken
up, that thread deallocates the semaphore so other threads can use it.
There may be other solutions of course. The number of semaphores restricts
the number of threads which can block. This doesn't seem a particularly bad
restriction. Although the overhead of allocating/deallocating a semaphore
could be slightly annoying.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine