<br><br><div class="gmail_quote">2012/7/2 Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
POSIX has no requirements that the pthread key operations be safe to call from an ISR so you are primarily concerned about<br>
<br>
+ memory allocation protection, if there is any<br>
+ dispatch disable, preventing other threads from running<br>
<br>
The methods which use _XXX_Get to turn an id into a pointer implicitly disable dispatching. So this part should be ok<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div> </div><div>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?<br>
<br>I also have some questions on current implementation's critical region proccessing:<br>- 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?<br>
- 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()?<br>
- 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?<br><br>links:<br>[0] My current implementation:<a href="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</a><br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="HOEnZb"><font color="#888888">
--joel<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br>
<br>
>On 07/02/2012 12:50 PM, Ashi wrote:<br>
>> I'm thinking about how to deal with critical region in my POSIX key project. My<br>
>> current approach is the one-rbtree approach, that is the critical region are<br>
>> one global rbtree which contains all the keys' data value and the chain-list in<br>
>> each thread's TCB. I'm confused with _Thread_Disable_dispatch() and<br>
>> _ISR_Disable(_level). What's the difference between them? Does _ISR_Disable()<br>
>> disable thread dispatch?<br>
><br>
>Single processor RTEMS systems require one hardware mechanism to ensure<br>
>protection of critical sections against concurrent access.  Concurrent access<br>
>in a single processor system can only occur due to interrupts.  Thus the<br>
>protection mechanism is disabling and enabling of interrupts.  The high level<br>
>synchronization primitives like events, semaphores, mutexes, barriers, message<br>
>queues, etc. are based on such critical sections.<br>
><br>
>The _ISR_Disable/Enable/Flash is something like a big kernel lock.<br>
><br>
>In order to avoid some large critical sections the thread dispatch disable<br>
>level was introduced.  It protects code sections from interruptions due to<br>
>thread dispatching.  Sections protected by _Thread_Disable_dispatch() are not<br>
>automatically protected from interruption by an interrupt service.  The<br>
>_Thread_Disable_dispatch() is also a non-blocking operation.<br>
><br>
>> I also find some operations like _RBTree_Find(),<br>
>> _Chain_Insert() in the RBTree API and Chain API call _ISR_Disable(), and some<br>
>> operation like _Objects_Get() which is called by _POSIX_Keys_Get() calls<br>
>> _Thread_Diable_dispath().<br>
>> BTW, I also checked the IRC meeting log, and find Joel has said "allocating<br>
>> memory from the workspace is a different lock than thread disable dispatch".<br>
>> Joel, what are the details of the different lock?<br>
><br>
>The memory allocation uses the _RTEMS_Lock_allocator() lock.  This is a<br>
>potentially blocking operation.<br>
><br>
>--<br>
>Sebastian Huber, embedded brains GmbH<br>
><br>
>Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany<br>
>Phone   : <a href="tel:%2B49%2089%2018%2090%2080%2079-6" value="+4989189080796">+49 89 18 90 80 79-6</a><br>
>Fax     : <a href="tel:%2B49%2089%2018%2090%2080%2079-9" value="+4989189080799">+49 89 18 90 80 79-9</a><br>
>E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a><br>
>PGP     : Public key available on request.<br>
><br>
>Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
>_______________________________________________<br>
>rtems-devel mailing list<br>
><a href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a><br>
><a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
<br>
_______________________________________________<br>
rtems-devel mailing list<br>
<a href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Best wishes!<br>Zhongwei Yao<br><br>