Semaphore release - not owner of resource return

[Joel Sherrill]

Manuel Coutinho wrote:
>
> Hi
>
>  
>
> Was checking some RTEMS code and stumbled upon the error 
> RTEMS_NOT_OWNER_OF_RESOURCE when we do a semaphore release -> threadA 
> obtains a semaphore and threadB releases it.
>
> From what I understood, this error can only happen with a binary 
> semaphore with priority inherence or ceiling.
>
>  
>
>  
>
> extract of the rtems_semaphore_create directive:
>
>  
>
> if ( _Attributes_Is_*binary*_semaphore( attribute_set ) ) {
>
>       the_mutex_attributes.lock_nesting_behavior = 
> CORE_MUTEX_NESTING_ACQUIRES;
>
>  
>
>       switch ( the_mutex_attributes.discipline ) {
>
>         case CORE_MUTEX_DISCIPLINES_FIFO:
>
>         case CORE_MUTEX_DISCIPLINES_PRIORITY:
>
>           the_mutex_attributes.only_owner_release = FALSE;
>
>           break;
>
>         case CORE_MUTEX_DISCIPLINES_PRIORITY_CEILING:
>
>         case CORE_MUTEX_DISCIPLINES_PRIORITY_INHERIT:
>
>           the_mutex_attributes.only_owner_release = TRUE;
>
>           break;
>
>       }
>
>     }
>
>  
>
> My question is: why does this give an error with binary and not with 
> simple binaries?
>
>  
>
> From what I understand about this functionality, a use for this could 
> be when the thread (threadA) is taking a long time or is in error and 
> another thread (threadB) tries to release all the semaphores that 
> threadA obtained and afterwards wants to delete threadA (or something 
> of the sort). So this, in principle, could be valid for both binary 
> and simple binary semaphores, no?
>
>  
>
> Is there an implementation issue as to why this is not possible to do 
> with binary semaphores (am just guessing, but if this is possible with 
> simple binary…why not with binary)?
>
Simple binary are used by applications to do condition synchronization. This
means the sem is created locked, taskA blocks waiting for signal 
(unlock) and
an isr or taskB unlocks it to unblock taskA.  By design and intention, the
task that locks is NEVER the unlocking task.

In contrast RTEMS binary semaphores (e.g. mutexes) are used for critical
sections (a.k.a. mutual exclusion) and are always locked/unlocked by the
same thread.
>
>  
>
> Thanks
>
> Kind Regards
>
> Manuel Coutinho
>