[GSoC]deal with the critical region in POSIX Key

[Ashi]

2012/7/2 Joel Sherrill <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?
- 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()?
- 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?

links:
[0] My current implementation:
https://github.com/ashi08104/rtems/blob/one_rbtree/cpukit/posix/src/keygetspecific.c

> --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
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> 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/20120703/b11f1840/attachment-0001.html>