On 20/12/16 23:37, Chris Johns wrote:
On 21/12/2016 08:20, Gedare Bloom wrote:
I haven't fully understood the distinction. I get that C11 are
individually (and collectively) smaller. I don't entirely get what is
their time-space tradeoff or when they are less desirable.
There are a few advantages to self-contained resources like mutexes
for an API like C11 and POSIX.
1. All major POSIX implementations work this way. The libstdc++ code
base assumes it, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78677. The standard does
say POSIX create calls can return an error however it seems to be
assumed this does not happen. A change in RTEMS brings us closer to
the major implementations in this regard.
Also kernel synchronization objects in Linux, FreeBSD, etc. work like
this. What you cannot do with self-contained objects is using them in a
distributed system with distinct address spaces, e.g. a usage case RTEMS
was initially designed for. Here you need one level of indirection to
identify objects globally.
2. Performance. Sebastian's work with LibBSD, which is documented in
the recent v3 SMP report highlighted the cost in the object look up in
various hot parts of the kernel. This alone is a significant piece of
data.
3. Deterministic resourcing. If you can link an application and it
fits in memory the resource is allocated. There is no need to account
and adjust a configuration parameter in another area of the system.
This combines well with function section linking where we only have
the referenced code in the target executable which means only the
referenced resources are included.
4. Self-contained objects help dynamic loaded resource configuration.
You do not know what can or could be loaded dynamically and how
resources may be used or shared. A central base image configuration
leads to possible conflicts in resource allocation. The unlimited
patch back in the mid-90's was one solution to this problem,
self-contains objects is another.
5. The objects reside in a table, e.g. they are suspect to false sharing
of cache lines.
6. No global registry means no global bottleneck for dynamic systems
that create/destroy synchronization objects in the hot path (e.g. OpenMP
support via libgomp). See https://devel.rtems.org/ticket/2274, e.g.
barrier bench on 24 processor T4240 783s vs. 5.7s (self-contained).
--
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
