SMP: ISR disable/enable vs. mutual exclustion
gedare at rtems.org
Mon Nov 18 17:18:11 UTC 2013
On Mon, Nov 18, 2013 at 4:42 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> 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
>> 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.
> 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
More information about the devel