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

[Jennifer Averett]

Has there been any work done on adding an
additional lock which allows nesting?   I'm going through
a list of capture engine modifications and the addition of an
SMP nesting interrupt lock would be appreciated

Thanks

Jennifer

> -----Original Message-----
> From: devel [mailto:devel-bounces at rtems.org] On Behalf Of Chris Johns
> Sent: Friday, July 11, 2014 6:08 PM
> To: devel at rtems.org
> Subject: Re: [PATCH 3/4] capture: Remove nested
> rtems_interrupt_lock_acquire calls.
> 
> 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
> 
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel