[GSoC]The overheads caculation of POSIX Key

[Gedare Bloom]

On Mon, Aug 20, 2012 at 3:01 AM, Ashi <ashi08104 at gmail.com> wrote:

> 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.
>
> I think it is a good idea to configure the number of keys independent of
the number of threads.


> 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?
>
> Probably in cpukit/sapi/include/confdefs.h Check for how the macro is used
/ propagates in that file.


> 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/20120821/c103b61a/attachment-0001.html>