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
