RTEMS Chain API and SMP

[Gedare Bloom]

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.huber at 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.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