Some problems with the libbsd update

[Sebastian Huber]

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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.