[GSoC]The overheads caculation of POSIX Key

[Ashi]

Hi, all. This post is about the overheads calculation of POSIX Key. We
haven't reach a resolution about what to do with this. Thanks for any
advice!

One problem of old POSIX Key is: extra memory is reserved in keys for each
thread or task, which can be heavy memory overhead. Now in current
one-rbtree implementation of POSIX Key, each key's data isn't allocated
until one thread(or task) sets its key data. But RTEMS system still need
reserve enough workspace memory for all possible key's data. For example,
there are 32 threads and 1 key in system. And only 1 thread need key data,
then other 31 thread data is not used and reserved. I'm not sure whether it
is necessary to provide user a option to set the upper bound of the key
data number in system. If it is necessary, I think we can add something
like CONFIGURE_MAXIMUM_THREAD_KEY_DATA, it can be from 1 to #max key * #max
thread. If we reach the upper bound, we can return ENOMEM in the key
setspecific function as the POSIX standard[0] allows.

Another problem: I find there is only maximum keys
configuration:CONFIGURE_MAXIMUM_POSIX_KEYS, but how and where does RTEMS
determine the proper workspace size for all POSIX Key data?

links:
[0]
http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_setspecific.html
-- 
Best wishes!
Zhongwei Yao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20120820/adab8361/attachment.html>