[lwip-devel] [task #7212] Add Mutex concept in sys_arch

[Jonathan Larmour]

Follow-up Comment #4, task #7212 (project lwip):

Re comment #2:

Yes I guess it could be done like the unix port. It just makes me
uncomfortable to optimise for the uncommon case. But I guess it's no big
deal.

>>The problem with mutexes in some places like the memp code is
>> that, for example, you may be doing a pbuf_alloc(PBUF_POOL,...
>> from an interrupt context (due to a new incoming packet), and
>> in an interrupt context you cannot block. Which means you can't
>> block on a mutex.
>
> I suppose the solution I use is the same for most of
> developers:
> I got a Rx-Task which wait a Rx-event. The Rx-Interrupt disable
> the RX interruption, and signal the Rx-event. So, the Rx-Task
> is wake-up, process all incoming packets, put them in
> PBUF_POOL, and last, enable the RX interruption. It allow to
> process in the thread the job the IT should do (a kind of DPC
> instead of ISR processing). 

That's rather inefficient. You need a task just to process incoming packets,
separate from the tcp/ip task. That's a whole extra thread stack and context
switch overhead. I don't think that's what most developers would do. (or at
least would want to do if they had an alternative). They'd want to pass the
packets directly to the lwip tcpip thread. 

We must not rely on such a model. My port does not do it for sure. The old
eCos port did, but that was very wasteful.

That's why SYS_ARCH_PROTECT exists for memp and pbuf allocation.  Otherwise
it would have always used only semaphores.

Re comment #3: While it is consistent with the sys API, it suffers the same
problem as the current sys API as it implies dynamic allocation of mutexes, or
allocation from a fixed pool. This has caused me problems on my own port
meaning calling mem_malloc, which is a bit poor really since most of the
mboxes or semaphores in use at present could have their memory allocated
statically.

Instead how about:
err_t sys_mutex_new(sys_mutex_t *mutex);
err_t sys_mutex_lock(sys_mutex_t *mutex);
void sys_mutex_unlock(sys_mutex_t *mutex);
void sys_mutex_free(sys_mutex_t *mutex);

where sys_mutex_t is a type defined by the port - probably a straight typedef
of the OS's mutex type.

I'd love to change the semaphore and mbox APIs too, but I'll leave that
thought for another day.

Note that I have sys_mutex_lock() returning success/failure. That's because
some OSes can return errors on lock (e.g. if they are broken out of the wait).
Although I'm not sure whether that's something we should worry about or not.
Perhaps we should leave it to the port to just throw its own assertion failure
in that case. Thoughts?

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?7212>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/