On 22/08/18 09:50, Sebastian Huber wrote:
To support everything in RTEMS is a lot of work, so I have to make
some trade-offs. The implementation of this API must be as efficient
as possible since it is used in the critical paths of the network
stack. I will try to use a single global epoch and thread-specific
records as suggested by Matthew Macy to avoid the need for
per-processor data structures and the thread pinning. One key issue is
that epoch records must not be destroyed:
https://www.mankier.com/3/ck_epoch_register
The consequence of this is that unlimited thread objects may lead to
undefined behaviour with this implementation approach. Also
thread-local storage cannot be used since it is reinitialized once a
thread restarted or reused. The epoch record must be included in the
Thread_Control and must not be touched by _Thread_Initialize(). This
means I have to move the API and its implementation along with the
Concurrency Kit to RTEMS.
Ok, there is also an
http://www.concurrencykit.org/doc/ck_epoch_unregister.html
and
http://www.concurrencykit.org/doc/ck_epoch_recycle.html
This allows a localized implementation in libbsd.
Due to performance reasons this requires the use of thread-local
storage. Any objections to make thread-local storage a hard requirement
for libbsd support?
--
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
