SMP: ISR disable/enable vs. mutual exclustion

[Gedare Bloom]

On Mon, Nov 18, 2013 at 4:42 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> 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.
>
No objection from me. Unfortunately users that have started with the
existing sapi rbtree will not get an error if they use the regular
functions.. But we can make the _unprotected variants disappear.

I only made the "protected" variants so the interface was like chains.
I prefer to have unprotected versions now.

-Gedare

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