On 23/07/15 13:51, Joel Sherrill wrote:
On 7/23/2015 6:36 AM, Sebastian Huber wrote:
On 23/07/15 12:29, Chris Johns wrote:
I feel this needs to be a real API not a pseudo-internal API. Making
this an API means the project agrees to support the API, it has tests
and we have to make sure it is working for a release. Oh and it has
documentation.
For an API I suggest to use C11/C++11:
http://en.cppreference.com/w/c/thread
For GCC this is done via this API:
https://gcc.gnu.org/viewcvs/gcc/trunk/libgcc/gthr.h?revision=219188&view=markup
So to parrot back a simple version of what you are proposing.
+ Add simple, self-contained objects for use in supporting
performance critical support components (e.g. FreeBSD,
gcc, newlib, OpenMP).
+ I assume that other language run-time layers may benefit
from this.
+ Use these lighter objects to reimplement gxx wrappers.
One question is how much of the C11/C++11 threading and synchronization
will be covered by self-contained objects.
Covered by self-contained objects would be:
* mutexes
* semaphores
* condition variables
* general futex support
NOT covered would be:
* threads
* POSIX keys
I theory we could also do this for threads as well, but this is quite
labour intensive. For POSIX keys, thread-local storage (TLS) could be
used instead.
--
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
