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

Gedare Bloom gedare at rtems.org
Tue Dec 20 21:20:10 UTC 2016


On Fri, Dec 16, 2016 at 11:26 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> 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.
>
> I created two tickets:
>
> https://devel.rtems.org/ticket/2842
> https://devel.rtems.org/ticket/2843
>
> Joel, Gedare, what is your opinion with respect to C11 mutexes?
>
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. I would
like to see a table that compares/contrasts these in a simple way to
evaluate. I will try to look closely at these different approaches in
a few weeks.

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