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.
Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
