Interesting. On our 40Mhz Coldfire CPU, one of our developers did note how the
RTEMS semaphore calls were slow.
So currently the self-contained objects are more efficient, but do not provide
as many real-time features. Your changes to convert the POSIX objects to
self-contained would help improve the efficiency of POSIX synchronization
objects, but a few Classic RTEMS APIs may still be needed.
If I could rank them:
RTEMS Classic API – most feature complete for real time systems, least
standard, least efficient
POSIX API – somewhat feature complete for real time systems, somewhat standard,
more efficient with self-contained changes
C11, C++11, OpenMP – Not as feature complete, most standard, most efficient
Does that make sense?
Would the POSIX synchronization objects be as efficient as C11 objects once
converted to be self-contained?
Thanks,
Alan
On 12/21/16, 9:19 AM, "Sebastian Huber" <sebastian.hu...@embedded-brains.de>
wrote:
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
