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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
