rtems_semaphore_obtain question

[Joel Sherrill]

On April 22, 2015 11:28:45 AM CDT, "Miller, Scott A." <scott.miller at swri.org> wrote:
>We have a question about how the RTEMS binary semaphore behaves when
>attempting to take the semaphore twice within the same task context.
>
>
>1. To create the semaphore, we run:
>
>
> rtems_semaphore_create(
>        rtems_build_name('M','U','T','\0') + _al_bsem_mutex_cnt,
>        1, /* FULL - since we are using this for mutual-exclusion */
>        RTEMS_BINARY_SEMAPHORE |
>        RTEMS_PRIORITY |
>        RTEMS_LOCAL |
>        RTEMS_INHERIT_PRIORITY,
>        0,  
>        sem_p);
>
>
>2. We then attempt to take it once, and it succeeds. We use:
>
>
>    rtems_semaphore_obtain(
>            *sem_p,
>            RTEMS_WAIT,
>            _Timespec_To_ticks(to));
>
>
>3. We then take it again (from the same task context), and it succeeds.
>Again, we use:
>
>
>    rtems_semaphore_obtain(
>            *sem_p,
>            RTEMS_WAIT,
>            _Timespec_To_ticks(to));
>
>                  
>
>We did not expect that (3) would succeed. If we attempt step (3),
>except from another task context, it fails (as expected).
>
>
>Is it expected that (3) should succeed, given it is running in the same
>task context? The documentation does not appear to say, but perhaps we
>are missing something?


Nested access is supported. The binary semaphore is owned by a thread. If it locks it again, that's ok. It just has to unlock it the corresponding number of times before it is really unlocked.

The other thread doesn't own it and it is locked by the first thread. Hence it blocks
--joel