[GSoC]deal with the critical region in POSIX Key

[Joel Sherrill]

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

--joel

Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:

>On 07/02/2012 12:50 PM, Ashi wrote:
>> I'm thinking about how to deal with critical region in my POSIX key project. My
>> current approach is the one-rbtree approach, that is the critical region are
>> one global rbtree which contains all the keys' data value and the chain-list in
>> each thread's TCB. I'm confused with _Thread_Disable_dispatch() and
>> _ISR_Disable(_level). What's the difference between them? Does _ISR_Disable()
>> disable thread dispatch?
>
>Single processor RTEMS systems require one hardware mechanism to ensure 
>protection of critical sections against concurrent access.  Concurrent access 
>in a single processor system can only occur due to interrupts.  Thus the 
>protection mechanism is disabling and enabling of interrupts.  The high level
>synchronization primitives like events, semaphores, mutexes, barriers, message 
>queues, etc. are based on such critical sections.
>
>The _ISR_Disable/Enable/Flash is something like a big kernel lock.
>
>In order to avoid some large critical sections the thread dispatch disable 
>level was introduced.  It protects code sections from interruptions due to 
>thread dispatching.  Sections protected by _Thread_Disable_dispatch() are not 
>automatically protected from interruption by an interrupt service.  The 
>_Thread_Disable_dispatch() is also a non-blocking operation.
>
>> I also find some operations like _RBTree_Find(),
>> _Chain_Insert() in the RBTree API and Chain API call _ISR_Disable(), and some
>> operation like _Objects_Get() which is called by _POSIX_Keys_Get() calls
>> _Thread_Diable_dispath().
>> BTW, I also checked the IRC meeting log, and find Joel has said "allocating
>> memory from the workspace is a different lock than thread disable dispatch".
>> Joel, what are the details of the different lock?
>
>The memory allocation uses the _RTEMS_Lock_allocator() lock.  This is a 
>potentially blocking operation.
>
>-- 
>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
>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