Thread-Local Storage, C++ Support and SMP

[Gedare Bloom]

On Fri, Jul 5, 2013 at 3:33 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 07/05/2013 03:10 AM, Gedare Bloom wrote:
>>
>> 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.
>
>
> Its good that you work on this.  Is it possible to get an overview of the
> data structures and objects involved, because I am not that happy with some
> parts of the patch posted to the list.
>
Sure. The code exists in various branches at
https://github.com/ashi08104/rtems/branches

We have it like:
Key Objects are managed as Score Objects. A global tree contains all
of the values, searched first by pthread_key_t and then by thread_id.
A per-thread chain is maintained in the POSIX API Extensions for the
thread's key values for iterating during destructors. The values
themselves are either pre-allocated or pool allocated in a free list.

For a long time we looked at using an Score Object per Key Value, but
the overhead is high.

> I would do it as follows:
>
> Normal key objects which provide a tree root for key values (the thread ID
> is the tree key), e.g. no global tree.
>

We chose not to do one tree per key, although I suppose we can
revisit. I think I argued against it, but do not remember the reasons
now. Maybe overhead, or complexity? I forget. I think it is not too
hard to change to one Rbtree per Key Object.

> Key values are part of the corresponding key tree and in a list of key
> values for the corresponding thread.
>
> Each thread has a list of key values which is used to call the key
> destructors for the key values associated with the thread.
>
> The key values are not objects, but are pre-allocated in chunks.  So we have
>
> Configuration = {
>   .maximum_key_values = X | rtems_resource_unlimited(Y);
> }
>
> In case no free key values are available we allocate a new chunk if the
> resource is unlimited or fail otherwise.
>
Yes, this is how we have done it too. The approach will introduce a
hopefully useful free list implementation that will need some extra
review and fix, but aims to be like a lightweight "slab allocator" for
the Score.

>
> --
> 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.