[GSoC]deal with the critical region in POSIX Key

[Ashi]

2012/7/4 Sebastian Huber <sebastian.huber at embedded-brains.de>

> On 03/07/12 12:06, Ashi wrote:
>
>> 2012/7/2 Joel Sherrill<joel.sherrill@**oarcorp.com<joel.sherrill at oarcorp.com>
>> >
>>
>>  POSIX has no requirements that the pthread key operations be safe to call
>>> from an ISR so you are primarily concerned about
>>>
>>> + memory allocation protection, if there is any
>>> + dispatch disable, preventing other threads from running
>>>
>>> The methods which use _XXX_Get to turn an id into a pointer implicitly
>>> disable dispatching. So this part should be ok
>>>
>>>
>>>  Sorry, dump question... Joel, do you mean what I need to do is just
>> mimic
>> the current implementation:do thread disable dispatch as the current
>> implementation?
>>
>> I also have some questions on current implementation's critical region
>> proccessing:
>> - Since key is only used after creation,  there is only one thread can
>> access key before key creation finish, then there is no race condition in
>> key create. Why there still is thread dispatch disable when key creates?
>>
>
> You have to make sure that resources are not left over in case someone
> deletes the thread.

Sorry, it's my mistake that assume  there is only one thread can access key
before key creation finish. I find if thread dispatch is not disabled
during key create and other thread is created before it, then there will be
two thread can access key, the key is needed protection.

>
>  - When key getspecific in one-rbtree implementation, the only operation
>> which relates to critical region(the rbtree) is _RBTree_Find[0], and
>> _RBTree_Find is ISR disabled. Then can we enable thread dispatch just
>> after
>> _POSIX_Keys_Get()?
>>
>
> In case task/ISR synchronization is not necessary, then a ISR disable
> during the find operation is not appropriate.  You should use the
> unprotected version.

I see.

 - I also find in current implementation, when pthread_getspecific failes,
> it returns NULL, but it didn't re-enable thread dispatch, what's the reason
> behind it?
>

Please have a look at _Objects_Get().
>
> Great, I know the reason now:)

>
>  links:
>> [0] My current implementation:
>> https://github.com/ashi08104/**rtems/blob/one_rbtree/cpukit/**
>> posix/src/keygetspecific.c<https://github.com/ashi08104/rtems/blob/one_rbtree/cpukit/posix/src/keygetspecific.c>
>>
> [...]
>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
> Phone   : +49 89 18 90 80 79-6
> Fax     : +49 89 18 90 80 79-9
> E-Mail  : sebastian.huber at embedded-**brains.de<sebastian.huber at embedded-brains.de>
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ______________________________**_________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/**listinfo/rtems-devel<http://www.rtems.org/mailman/listinfo/rtems-devel>
>



-- 
Best wishes!
Zhongwei Yao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20120704/85d41f94/attachment-0001.html>