RTEMS Chain API and SMP
gedare at rtems.org
Fri Mar 7 16:45:59 UTC 2014
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
I think this is acceptable.
On Fri, Mar 7, 2014 at 11:12 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> 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:
> 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.
> * 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
> * The protected chain operations work correctly on SMP.
> * 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
More information about the devel