RTEMS SMP Status Report v3

[Sebastian Huber]

On 23/12/16 02:01, Chris Johns wrote:
> On 22/12/2016 21:43, Sebastian Huber wrote:
>> ----- Chris Johns <chrisj at rtems.org> schrieb:
>>> On 22/12/2016 01:19, Sebastian Huber wrote:
>>>> The POSIX API provides no binary semaphores, so task/interrupt
>>>> synchronization is a problem. So, for drivers there is still a need 
>>>> for
>>>> some RTEMS-specific APIs.
>>>
>>> I like the idea of NP additions help us here. We already have
>>> pthread_getaffinity_np.
>>
>> I don't like the idea of adding RTEMS-specific pthread_*_np() functions.
>
> I do not really understand the reasons why. It seems you are ok with 
> "standard" non-standard calls but not "non-standard" non-standard or 
> "RTEMS" non-standard calls. I see any NP call as non-standard no 
> matter the acceptance or availability and I also think it is a good to 
> borrow NP calls where they exist rather than invent them however it 
> does not give them an elevated standing.

If glibc/Linux adds a feature its a de-facto standard.

>
>> The pthread_getaffinity_np(), etc. was invented by glibc (probably?).
>
> I do not know.
>
>> I don't think RTEMS should be the trendsetter in this area.
>
> Why not lead in this area?
>
>> It confuses users to have NP functions that are RTEMS-specific and NP 
>> functions that are available on Linux/BSD.
>
> I am not sure why you think this is an issue. There are NP calls on 
> FreeBSD we do not support so using NP for portable code requires extra 
> effort from users. I think it would be a mistake to let users think 
> otherwise. Any code that uses RTEMS NP calls may not build on Linux or 
> FreeBSD and this is the same as using the Classic API so the gain is 
> neutral.

Up to now every pthread NP function available in RTEMS is available on 
glibc.

>
> I like the idea of ELF notes being used to tag every API function in 
> RTEMS with the standard and API they come from. We can then have a 
> tool to audit the executable. There was a post recently from Nick 
> Clifton on binutils about annotating ELF binaries this way. Linux also 
> has code to add notes to ELF files.
>
>>
>> QNX has a list of non-POSIX functions with POSIX-sounding names:
>>
>> http://www.qnx.com/developers/docs/am11/index.jsp?topic=%2Fcom.qnx.doc.neutrino.prog%2Ftopic%2Fposix_conformance_POSIX_sounding.html&cp=1_3_1_10_2 
>>
>>
>> The gray area is task/interrupt synchronization. I didn't find 
>> something useful on the QNX page.
>>
>
> Looks like they wedged themselves a little bit with some NP tagged 
> calls and others not NP tagged. We should avoid this.

Yes, definitely.

>
>> What we definitely need is something like a binary semaphore (a one 
>> bit event).
>
> Yes and a way to manage some extra threading parameters we have.
>
> How do you propose we add such an API so it fits in with a POSIX API 
> that has been changed to be self-contains and faster?
>
> We have just dangled a carrot in front of our users so it would be 
> great to find a workable path forward. :)
>
> Chris

Maybe add a PTHREAD_MUTEX_SIMPLE_NP mutex type.

I still prefer a small special purpose API in <rtems/mutex.h> and 
<rtems/semaphore.h> for everything required by general purpose libraries 
and device drivers, e.g. priority inheritance mutexes, binary and 
counting semaphores.

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