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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
