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

[Chris Johns]

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

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.

Chris