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.hu...@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@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
