On Wed, Aug 22, 2018, 4:51 AM Sebastian Huber < 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. Certainly seems like the mist straightforward approach to solving the problem. But it requires some work on TLS which was needed anyway. > > -- > 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
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
