[lwip-devel] [task #6683] Document lwIPs thread safety requirements

[Jonathan Larmour]

Follow-up Comment #7, task #6683 (project lwip):

First of all, with respect to interpretation of NO_SYS etc., IMHO we can lay
down new policy, irrespective of what was originally intended. Clearly things
are a bit muddy at present anyway.

Secondly, as well as interaction between apps and lwIP, I think more
attention is needed with the intended interface between ethernet (or serial?)
drivers and lwIP. This affects SYS_LIGHTWEIGHT_PROT for example: should it
disable tasking or interrupts? Must drivers call into the stack in an
interrupt context or a task context? Or can ports do either, as long as they
code appropriately? I suspect at the moment ports do either, but I for one am
not sure that this can work reliably (at least in the current code - maybe
that can be changed). A key issue is whether drivers (or code called from
drivers) can wait on synchronisation objects - possible from task or high
level interrupt context (aka bottom half aka deferred service routine, etc.),
but not a low level interrupt context.

As an example, if a driver called tcpip_ethinput() in current CVS from a low
level interrupt context, then that in turn calls memp_malloc and
sys_mbox_post. Okay, memp_malloc can be protected with SYS_LIGHTWEIGHT_PROT
and interrupts disabled, but sys_mbox_post can be a problem: OS-provided
mailboxes may not be interrupt-safe - they may only be intended to be
task-safe. This is true for eCos and no doubt others. You also can't just
disable interrupts around the call either because posting to a mailbox can
cause a task switch, which, if interrupts are off, would cause all sorts of
bad things. If lwIP requires people to write their own mailbox implementation
as part of the "OS abstraction" then I don't think the OS abstraction can be
quite right.

The "solution" is to ensure that tcpip_ethinput is not called from an
interrupt context - it must either be called from a thread or from a high
level interrupt handler aka bottom half aka deferred service routine aka
other names on other systems. Not all systems have such facets to their
interrupt handling though.

Anyway, this is was only meant to be one example where thread interactions
are unclear, and why we need more clarity.


    _______________________________________________________

Reply to this item at:

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

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