This will make the protected Chain API stuck (for now, possibly forever) with coarse-grained locks, but users can define their own fine-grained locking implementations of chains using unprotected chain API calls?
I think this is acceptable. Gedare On Fri, Mar 7, 2014 at 11:12 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > Hello, > > I am glad that we had no RTEMS 4.11 release yet. I have to revisit the > RTEMS chain API. > > This solution was a bad mistake as it runs out now: > > http://git.rtems.org/rtems/commit/cpukit/sapi/include/rtems/chain.h?id=1215fd4d9426a59d568560e9a485628560363133 > > In order to support profiling of SMP locks and provide a future compatible > SMP locks API I have to add an SMP lock destroy function. Since the patch > adds an SMP lock to each chain control we would have to add a > rtems_chain_destroy() function as well. This is complicates the chain usage > dramatically. So I propose to revert the patch above. A global SMP lock > for all chains should be use to implement the protected chain operations. > > Advantages: > > * The RTEMS chain API is now identical on SMP and non-SMP configurations. > > * The size of the chain control is reduced and is then equal to the Score > chains. > > * The protected chain operations work correctly on SMP. > > Disadvantage: > > * Applications using many different chains and the protected operations may > notice lock contention. > > I think the chain control size drop is a huge benefit (RTEMS chain controls > are 66% larger than the Score chain controls). The only disadvantage is not > really a problem since these applications can use specific interrupt locks > and unprotected chain operations to avoid this issue. > > -- > 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