[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] Require sys_arch_protect/unprotect to be correctly nest
From: |
Joel Cunningham |
Subject: |
Re: [lwip-devel] Require sys_arch_protect/unprotect to be correctly nested? |
Date: |
Wed, 19 Jul 2017 17:52:32 -0500 |
> On Jul 19, 2017, at 5:12 PM, Douglas <address@hidden> wrote:
>
> 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.
I’m not familiar with using the DECL_PROTECT to keep track of recursion level.
I’m familiar with using it to store the interrupt state returned by the disable
interrupts API, which is then required in the enable interrupts API. Some
spinlock APIs (which SYS_ARCH_PROTECT can be used with on git HEAD) also
require storing the state between lock and unlock calls. So removing
DECL_PROTECT and level would eliminate the use of disable/enable interrupts and
spinlocks on any RTOS platform that works this way
>
> 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.
>
I’m not sure if there’s a good use case for recursively calling PROTECT. Maybe
Simon can weigh in on whether this was intended or a bug.
Joel