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" < [email protected]> 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@embedded-**brains.de<[email protected]> > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > ______________________________**_________________ > rtems-devel mailing list > [email protected] > http://www.rtems.org/mailman/**listinfo/rtems-devel<http://www.rtems.org/mailman/listinfo/rtems-devel> >
_______________________________________________ rtems-devel mailing list [email protected] http://www.rtems.org/mailman/listinfo/rtems-devel
