C11 Re: [PATCH 3/6] termios: Use C11 mutex for input/output
Sebastian Huber
sebastian.huber at embedded-brains.de
Wed Dec 21 06:29:08 UTC 2016
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.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel
mailing list