POSIX performance

[Joel Sherrill]

Till Straumann wrote:

> Alexander I. Shaykhrazeev wrote:
>
>> Did somebody check performance of POSIX semaphores and other 
>> functions against RTEMS own?
>>
>
> A while ago I compared vxworks, rtems and RT-linux regarding
> interrupt and thread dispatching latency.
> Both, rtems native and posix APIs were used.
>
> See
>
> http://www.slac.stanford.edu/econf/C011127/WEBI001.shtml
>
> Note, however, that the paper incorrectly reports poor pthread
> performance under RTEMS. This was due to a programming error
> (incorrect task priority assignment). A repeated test using with
> the correct pthread priority yielded no significant difference in
> performance between RTEMS native and pthreads (for the
> latency benchmark - this was not a comprehensive comparison
> of all features or primitives, however).
>
 From a design viewpoint, there should be little difference between
the POSIX and Classic API objects performance.  Many are
based upon the same underlying SuperCore support and the API
code is just a thin wrapper.

+ POSIX threads and Classic tasks are SuperCore threads
+ POSIX mutex --> SuperCore Mutex
+ POSIX semaphore --> SuperCore Semaphore
+ Classic Semaphore --> SuperCore Mutex or Semaphore
+ POSIX and Classic message queues are SuperCore message queues

All blocking code is the same.  All delays/sleeps end up in the same helper
routines. 

The primary difference is going to be the overhead of translating the
API into SuperCore calls -- which should be in the noise as far as
differences.  The other thing to watch out for is semantic differences
which means that one API might actually have more functionality
required from what appears to be the same call.  For example,
POSIX message queues allow for priority based messages and
Classic API message queues are FIFO or LIFO.

--joel

> -- Till