Re: [lwip-devel] Require sys_arch_protect/unprotect to be correctly nested?

[Douglas]

On 07/20/2017 01:10 AM, Joel Cunningham wrote:
> 
>> On Jul 19, 2017, at 8:15 AM, Douglas <address@hidden> wrote:
>>
>> Most uses of sys_arch_protect/unprotect appear to be nested correctly,
>> so that it is unnecessary to note the current nesting level. It is not
>> uncommon for a recursive mutex implementation to not expose the level
>> and to require matching acquire and release operations. The FreeRTOS
>> vPortEnterCritical function does not return a nesting level.
>>
>> So would a change to require sys_arch_protect/unprotect to have matching
>> nesting be considered, perhaps even cleaning these up by removing the
>> *DECL_PROTECT macros and the levels?
> 
> The DECL_PROTECT and levels allow SYS_ARCH_PROTECT to be implemented as 
> disable/enable interrupts for a uni-processor system.

The DECL_PROTECT and levels are not necessary in order to implement
SYS_ARCH_PROTECT by disabling interrupts. The implementation can keep a
static variable counter of the nesting depth and when it gets to zero
can enable interrupts again.

Ensuring these are nested adds a new constraint that would allow this to
work on an OS in which the recursive level were not accessible and where
it is not possible to jump out of nested levels of protection by
supplying a depth.

For example using the FreeRTOS vPortEnterCritical function to implement
this. This function does not return the nesting level and if lwip code
were written that jumps out of recursive levels of protection then it
would complicate sys_arch_protect/unprotect.

It might also allow a recursive mutex to be used, and generally the
depth is not accessible.

Douglas