RTEMS and Google Summer of Code 2007

Joel Sherrill joel.sherrill at oarcorp.com
Mon Mar 5 21:08:53 UTC 2007


Pavel Pisa wrote:
> Hello Joel,
>
> On Monday 05 March 2007 13:26, Joel Sherrill wrote:
>   
>>> I am convinced still, that uLUt is not so bad replacement
>>> of some STL subset for old poor C.
>>>       
>> What's the license?  I am not sold on an implementation yet. :-)
>>     
>
> The uLUt license is GPL/LGPL/MPL and I am in position to release
> it under other licenses as well. I use RTEMS and GPL+RTEMS
> linking exception is fully OK for me. May it be, that hashes
> could be better choice for map. But hashes has problem, that you
> have to decide has size on beginning or you have to reallocate
> and refill hash array when it is too much filled.
>   
I am open for suggestions and advice and appreciate the license change 
offer.
My goal is to get fixed overhead out of each task for notepads and out of
every key.  Plus POSIX keys do not currently correctly handle the
unlimited thread configuration attribute so this would fix that.
> On the other hand, I believe, that GAVL or RB-tree are right
> choice for timer queues with high resolution.
>   
I am not thinking about high resolution timer queues yet but that is
a wish list item for me.  My first goal is just to get high resolution time
stamps. :)

I am not sure which data structure is best.  I know the characteristics
of the data being mapped. 

+ The key is either a thread Id or TCB pointer.  So it is unique.
+ The value is a void * in either case.
+ We would need to dynamically insert entries on first use.
+ We would need to dynamic remove entries on thread deletion.

I think that a posix thread key is really a poor man's map anyway
so that seems like a natural fit.

The Classic API notepads are a bit different.  I would want one
"set" of Id->notepad array mappings and just look up the set
based upon the Id of the thread.  Basically very similar.

--joel
> Best wishes
>
>            Pavel
>   




More information about the users mailing list