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-boun...@rtems.org] On Behalf Of Chris Johns > Sent: Friday, July 11, 2014 6:08 PM > To: devel@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel