On 22/08/18 13:44, Joel Sherrill wrote:
On Wed, Aug 22, 2018, 4:51 AM Sebastian Huber <sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de>> wrote: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?Not particularly but there should be an effort to identify which targets do not have TLS support yet. Other than sparc, arm, powerpc and i386, I don't know the status. Sounds like a series of tickets.
TLS is also supported on m68k and riscv. Are the other targets maintained at all?
-- 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
