[PATCH 3/4] capture: Remove nested rtems_interrupt_lock_acquire calls.

[Chris Johns]

On 11/07/2014 4:59 pm, Sebastian Huber wrote:
> On 2014-07-11 04:08, Chris Johns wrote:
>> On 10/07/2014 11:44 pm, Jennifer Averett wrote:
>>> Use of the cenable command was resulting in a lock in
>>> rtems_interrupt_lock_acquire due to nesting.
>>
>> I am rejecting this change. RTEMS as an RTOS should provide support to
>> handle
>> this case in a consistent manner in SMP and non-SMP builds of the code.
>>
>> The change highlights an issue in RTEMS's locking support. This code
>> works on a
>> non-SMP build because the rtems_interrupt_lock_acquire nests and this
>> is the
>> functionality of the call it replaces. It is dangerous to promote
>> rtems_interrupt_lock_acquire and rtems_interrupt_lock_release as
>> replacements
>> for old interrupt disable and enable calls if they are not
>> functionally the
>> same as the code they replace and functionally the same on SMP and
>> non-SMP builds.
>>
>> I understand the current implementation of the rtems_interrupt_lock_*
>> code is
>> optimised for performance and adding nesting checks adds overhead
>> however I
>> feel we should considering providing support with no-nesting versions
>> for code
>> that can support this. The pattern in the capture engine this change
>> addresses
>> is a common one and forcing users to remember this issue and then
>> rewrite exist
>> code to manage it is not being a helpful RTOS.
>
> I am fine with adding additional locks which allow nesting,

Great.

> but the
> default lock used a the lowest level must not allow nesting.

I agree.

Chris