SMP: ISR disable/enable vs. mutual exclustion

[Sebastian Huber]

Hello,

I will likely work on the R-B tree implementation in the future (first step is 
to do some benchmarks) so I want to continue with this thread first.

On 2013-08-28 19:02, Gedare Bloom wrote:
>> The containers basic API should be without locking.
>> >You usually need something like atomic extract from one list
>> >and insert to the other list. And you waste additional
>> >locking in list remove/insert when you have to provide
>> >lock to make operations sequence atomic.
>> >There is usually good/natural place where lock belongs
>> >in such cases. Or you do not want to use IRQ+spin-lock
>> >there but whole sequence is protected by mutex (should be
>> >with priority inheritance for each case).
>> >
> I tend to agree. Let the "user" of the data structure handle the
> locking around it at least for RTEMS core code. But this means right
> now going through all of RTEMS core and replacing chain_xxx with
> chain_xxx_unprotected.
>
> Conversely, we make all the functions unprotected by default and
> introduce "_protected" variants for the API layer.
>

Are there any objections to remove the protected R-B tree functions from all 
APIs and provide only unprotected operations?  I would like to do this now 
(before the RTEMS 4.11 release) since there is currently no RTEMS release with 
the public R-B tree API.

-- 
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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.