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.hu...@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to