RTEMS SMP Status Report v3

[Sebastian Huber]

On 21/12/16 15:02, Cudmore, Alan P. (GSFC-5820) wrote:
> I agree, it’s an excellent report. Thanks for the SMP implementation in RTEMS, it is very important to our future work.
>
> In the past I have used the classic RTEMS API. For SMP applications, is there a preferred API? Does the POSIX API offer more control or features over the Classic API for SMP?

There is an discussion about self-contained objects and its use inside 
of RTEMS:

https://devel.rtems.org/ticket/2843

I would definitely use self-contained objects for an SMP application. I 
would also prefer a standard API to be as much as possible compatible to 
Linux. Currently available are OpenMP, C11 and C++11 (or FreeBSD kernel 
APIs via libbsd). They all lack support for various options interesting 
for real-time applications, e.g. binary semaphores, counting semaphores, 
priority ceiling mutexes, barriers, message queues, etc.

We should change the POSIX synchronization objects

* mutexes,
* rwlocks,
* barriers,
* condition variables,
* keys, and
* semaphores

into self-contained objects from my point of view. Since the POSIX types 
are now defined in a system-specific header file, this is quite easy:

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/sys/rtems/include/sys/_pthreadtypes.h;h=bd66c689ecf0a3ef335867b5a08d32f9dfe9041b;hb=HEAD 


Its about a man week of work to do this (more if certain defects of the 
POSIX implementation should be fixed).

The POSIX API provides no binary semaphores, so task/interrupt 
synchronization is a problem. So, for drivers there is still a need for 
some RTEMS-specific APIs.

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