On Mon, Nov 18, 2013 at 4:42 AM, Sebastian Huber <sebastian.hu...@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.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 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
