[GSoC]deal with the critical region in POSIX Key

[Ashi]

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

> 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.
>
> Sebastian, thanks for your clear explanation.

>
>  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.
>


>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

Joel, does it mean use _RTEMS_Lock_allocator()  before allocating anything
from workspace? If so, why is there no _RTEMS_Lock_allocator() in current
keycreate.c(there is _workspace_allocate() at line 80 in keycreate.c)?

>+ 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



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