[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-devel] RFC: SYS_ARCH_DECL_PROTECT makes no sense, remov e it

From: Pettinato, Jim
Subject: RE: [lwip-devel] RFC: SYS_ARCH_DECL_PROTECT makes no sense, remov e it
Date: Wed, 5 May 2004 15:57:59 -0400


Those of us using the raw API, NO_SYS, and attempting to allocate pbufs at
the driver level (in interrupt time) on a processor with nested prioritized
interrupts (i.e. 68K) find that protection mechanism invaluable. Simple
enabling/disabling of interrupts won't work in that case, because
SYS_ARCH_UNPROTECT can end up enabling ints within an interrupt service
routine that may not be reentrant and certainly could be invoked again if
the interrupt is still pending in the hardware. Both my Ethernet driver
(SMSC91C111) and SLIP driver make the occasional pbuf_alloc() call.

As the comments in the lwIP code and docs indicate, #defining these macros
as follows:

#define SYS_ARCH_DECL_PROTECT byte lvl;
#define SYS_ARCH_PROTECT (lvl = setintlvl(NMI_LVL))   // mask all interrupts
#define SYS_ARCH_UNPROTECT (setintlvl(lvl))           // restore previous
interrupt level

allows a safe way to assure that no ISR can interrupt the critical sections
of the pbuf and memory pool allocation routines, thereby corrupting them,
while also assuring that that interrupts are not inadvertently enabled when
calling pbuf and mem routines from an ISR.

My two cents - Keep it in. I'm using the macros as described above, and see
no harm in having them in place if you're using a more robust protection
scheme, as they are by default #defined out anyway. 

James M. Pettinato, Jr.
Software Engineer
FMC Measurement Solutions/Smith Meter, Inc.


>the SYS_ARCH_DECL_PROTECT protection mechanism makes
>no sense to me. It never did.

>It protects pbuf->ref count against concurrent read-write-modify actions,

>But as the rest of the pbuf fields and code is not protected against 
>concurrent use (let alone the rest of the lwIP core) I see no real world
use of it.

>RFC: Remove this from the stack.



lwip-devel mailing list
address@hidden http://mail.nongnu.org/mailman/listinfo/lwip-devel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]