<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 22, 2018, 4:51 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 22/08/18 09:50, Sebastian Huber wrote:<br>
> To support everything in RTEMS is a lot of work, so I have to make <br>
> some trade-offs. The implementation of this API must be as efficient <br>
> as possible since it is used in the critical paths of the network <br>
> stack. I will try to use a single global epoch and thread-specific <br>
> records as suggested by Matthew Macy to avoid the need for <br>
> per-processor data structures and the thread pinning. One key issue is <br>
> that epoch records must not be destroyed:<br>
><br>
> <a href="https://www.mankier.com/3/ck_epoch_register" rel="noreferrer noreferrer" target="_blank">https://www.mankier.com/3/ck_epoch_register</a><br>
><br>
> The consequence of this is that unlimited thread objects may lead to <br>
> undefined behaviour with this implementation approach. Also <br>
> thread-local storage cannot be used since it is reinitialized once a <br>
> thread restarted or reused. The epoch record must be included in the <br>
> Thread_Control and must not be touched by _Thread_Initialize(). This <br>
> means I have to move the API and its implementation along with the <br>
> Concurrency Kit to RTEMS. <br>
<br>
Ok, there is also an<br>
<br>
<a href="http://www.concurrencykit.org/doc/ck_epoch_unregister.html" rel="noreferrer noreferrer" target="_blank">http://www.concurrencykit.org/doc/ck_epoch_unregister.html</a><br>
<br>
and<br>
<br>
<a href="http://www.concurrencykit.org/doc/ck_epoch_recycle.html" rel="noreferrer noreferrer" target="_blank">http://www.concurrencykit.org/doc/ck_epoch_recycle.html</a><br>
<br>
This allows a localized implementation in libbsd.<br>
<br>
Due to performance reasons this requires the use of thread-local <br>
storage. Any objections to make thread-local storage a hard requirement <br>
for libbsd support?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Certainly seems like the mist straightforward approach to solving the problem. But it requires some work on TLS which was needed anyway.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : +49 89 189 47 41-16<br>
Fax     : +49 89 189 47 41-09<br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div></div>