[GSoC]use hash/map in POSIX key and Classic notepad

[Chris Johns]

On 6/04/12 4:33 AM, Joel Sherrill wrote:
> On 04/05/2012 01:06 PM, Gedare Bloom wrote:
>> On Thu, Apr 5, 2012 at 12:52 PM, Joel Sherrill
>> <joel.sherrill at oarcorp.com> wrote:
>>> On 04/05/2012 11:09 AM, Gedare Bloom wrote:
>>>
>> Yes that makes sense. I could see having an rbtree of the keys in a
>> posix thread extension. This would also avoid problems with collisions
>> between threads, especially since threads are allowed to specify the
>> same key for different data. Holding the keys in separate per-thread
>> structures seems the best solution. If the number of keys is expected
>> to be small then a linked list/chain would be fine too.
> Key IDs are unique so would be good as hash tags.
>
> Key lookup is assumed to be very fast. They are usually used
> by libraries like language run-times which need a "per-thread"
> context. Ada's POSIX implementation uses this unless you provide
> a more optimized solution.

I would expect the number of keys to be small per task. An application 
should be encouraged to use structures and not keys per piece of data.

> Go could use this but went with
> the Classic API per task variables which are lighter for access
> but heavier on context switch.

<sigh> This is a good case for adding keys to the Classic API. The 
existing notepad register API could be implemented as a pointer to the 
notepads held in a task key. Allocation becomes per task that use 
notepads and 0 if they do not.

>
> Putting the key values in the POSIX API thread extension
> requires you to consider the magnitude of deleting a key
> and finding out who used it. The memory per thread would
> have to be reclaimed.
>

We should think beyond the POSIX API and look at every possible way to 
remove the task var API from RTEMS. I am currently thinking about a 
prink message "warning: task variables in use, deterministic context 
switching questionable" in the create call.

Chris