C11 Re: [PATCH 3/6] termios: Use C11 mutex for input/output

[Sebastian Huber]

On 16/12/16 21:50, Chris Johns wrote:
> On 17/12/16 3:26 am, Sebastian Huber wrote:
>>
>> On 15/12/16 23:34, Chris Johns wrote:
>>> On 15/12/2016 18:02, Sebastian Huber wrote:
>>>> On 14/12/16 22:15, Chris Johns wrote:
>>>>> On 15/12/2016 00:39, Sebastian Huber wrote:
>> [...]
>>>>> Would the "tiny" footprint be smaller if all internal services
>>>>> including compiler thread support are made C11? Could this actually be
>>>>> done? Parts of POSIX has been creeping in over time so the position is
>>>>> a little confused at the moment. I am not sure about a bits and pieces
>>>>> approach, maybe a full switch is made.
>>>> Yes, the footprint would be smaller. If we provide self-contained
>>>> threads, then the footprint would be much smaller, e.g. no object
>>>> administration, no heap.
>>> Great. This is a powerful reason to look at moving in this direction
>>> and removing the remaining POSIX usage in libstdthreads.
>>>
>>> A brief audit of rtems.git shows the change is possible with less than
>>> 30 Classic task creates and a similar number of semaphore creates so a
>>> full change look reachable which is nice.
>>>
>>> Should we look at moving all internal services to C11 and standardise
>>> it? I think there is value in doing this. It can be a post 4.12 branch
>>> activity.
>> In contrast to the C11 mutexes, I don't see a real value in moving from
>> Classic API tasks to C11 threads. The Classic API you have more control
>> over task attributes, modes, priority, stack size, etc.
> As an interim solution this is possible but we should consider and plan
> the long term solution.
>
> I took a closer look at C11 threads and see the thread support is not
> suitable. I have concerns about mixing the API to get a "tiny" image and
> was hoping a single API could do this, ie the attributes of the API
> should be consistent across all calls and meet a minimum set of required
> functionality.
>
> The lack of thread attributes raises a difficult issue we need to
> consider a little more. I do not like the idea of a thread created with
> thrd_create and then needing attributes set by the another API. I
> thinking mixing is an architecturally poor path to follow.

The C11 threads are next be useless in the context of a real-time 
operating system with a priority based scheduler.

>
> The C11 mutex is thin and the storage model is attractive. The FreeBSD
> man page for C11 functions states:
>
>    As of ISO/IEC 9899:2011 (``ISO C11''), the C standard includes an API
>    for writing multithreaded applications.  Since POSIX.1 already
>    includes a threading API that is used by virtually any multithreaded
>    application, the interface provided by the C standard can be
>    considered superfluous.

I agree with the FreeBSD man page, however, the quite primitive and 
limited C11 mutexs and condition variables have one good side. There is 
no need to check at run-time in each operation which object flavour is 
used actually. For plain mutexes they are perfect.

>
> Should we be looking at the POSIX interface and doing this work there?
> That is move the POSIX implementation away from the RTEMS object model.
>
> Could this be done and would the same mutex performance be achieved?
>
> If the same storage model and performance can be gained with POSIX why
> not look at moving in this direction.

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.

The performance will be not optimal, since we have to check if we 
actually have a non-recursive, recursive, ceiling or robust mutex.

-- 
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.