rtems_semaphore_obtain question

Joel Sherrill joel.sherrill at oarcorp.com
Wed Apr 22 16:35:55 UTC 2015



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



More information about the users mailing list