RTEMS SMP Status Report v3

[Cudmore, Alan P. (GSFC-5820)]

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.huber at 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.huber at embedded-brains.de
    PGP     : Public key available on request.
    
    Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.