Realtime capable userspace?

[Stanislav Meduna <stano@meduna.org>]

Hi,

I know this is not a kernel-related question, but I think the amount of
people doing realtime here is probably the largest.

As learned the hard-way the glibc is not (yet) realtime capable and
first changes are now starting to trickle in. Even if I try to fix known
places, who knows what, where and for how long is locked.

What userspace (libc / threads / malloc) are you using for realtime
applications? From my quick research:

- glibc:
  - priority-inheritance mutex implemented, but never used inside
    the glibc
  - not easy to replace malloc used internally (so that e.g.
    strdup() uses another one), at least when using shared
    libraries

- ucLibc:
  - threads from glibc, malloc uses non-PI-aware locks

- newlib:
  - no PI support, no futexes, mutexes done via kill(treadid, signal)

- tcmalloc (gperftools)
  - no PI locks used, although it is probably easily added. Not sure
    about the state of the software generally - it probably got much
    less real-world testing than the implementation in glibc


I ended with own low-level implementation of synchronization primitives
I needed via futexes (fortunately no full condvars or semaphores
needed) and serializing all malloc/free/... cals via a PI-aware mutex
(I don't care for performance when contented here, but I do care for
priority inversion).

What do you use for non-trivial applications?

Thanks
-- 
                                   Stano