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

[Sebastian Huber]

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, but the default 
lock used a the lowest level must not allow nesting.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.