Thread-Local Storage, C++ Support and SMP

[Gedare Bloom]

Sebastian,
I have been working with the student to get the keys code mergeable. We
have one last problem which maybe we can fix later. We need a generic
freelist implementation for some unlimited mode allocations. This is a
boundary case and can be ignored for now. I will push for code we can merge
soon. It should fix #3 (not sure if cancellation was tested) and 4, and #5
when we get freelist merged. The code all exists just needs review, fix,
and merge.
-Gedare
On Jul 4, 2013 3:27 AM, "Sebastian Huber" <
sebastian.huber at embedded-brains.de> wrote:

> Hello,
>
> we added support for thread-local storage on PowerPC for C11 and GCC
> __thread.  The work on C++11 support revealed a couple of problems.
>
> 1. The general C++ support code is not SMP safe.  It uses task variables
> and disables preemption to ensure mutual exclusion.
>
> 2. The implementation of thread keys in the C++ support is not standard
> conform.  The destructors must be called during thread exit and
> cancellation.
>
> 3. The implementation of POSIX keys is not standard conform.  The
> destructors must be called during thread exit and cancellation.
>
> 4. The workspace estimate for POSIX keys is wrong.  It depends on the
> maximum thread count in the system times the maximum key count.
>
> 5. The POSIX keys are broken if someone uses unlimited thread objects.
>
> To address the C++ problems we propose:
>
> 1. Move the POSIX keys to the Classic API.
>
> 2. Implement the POSIX keys with the red-black tree instead of the fixed
> table lookup.
>
> 3. Fix the configuration issues.
>
> There was a GSoC project in 2012 for this which addressed parts of the
> above issues.  Where can I find the latest status of this project?
>
> --
> 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<sebastian.huber at embedded-brains.de>
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ______________________________**_________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/**listinfo/rtems-devel<http://www.rtems.org/mailman/listinfo/rtems-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130704/719b922a/attachment-0001.html>