Semaphore release - not owner of resource return

[Joel Sherrill]

Manuel Coutinho wrote:
> By the way, is there a special reason why locked binary semaphores cannot be
> deleted and simple binary semaphores can? (just came across this section of
> the code...)
>   

The general thinking is that when locked they indicate
some task is in a critical section.  If you delete them, then
you are potentially negatively impacting that critical
section.

There may also have been some discussion of how do you
deal with any inherited priority.

In general it avoids dealing with complicated side-effects
of cleaning up.

Simple binary semaphores are  used for condition
synchronization --not critical sections.  They are locked
when a task is waiting on someone to announce a
condition (e.g. often an ISR occurred).  The task waiting will
naturally wake up with RTEMS_OBJECT_WAS_DELETED.
So this one takes care of itself in a natural and clean way.
> I am thinking of this problem because of PR788 (Priority inheritance
> mechanism may activate a deleted task).
>
> If locked simple binary semaphores and locked binary semaphores are
> impossible to be deleted, then this bug may be fixed easily (since only
> these two types of semaphores can have priority inheritance protocol).
>
>   
Simple binary can't have inheritance or ceiling.  Only
true binary.

But go on... explain your idea.
> Thanks
> Kind regards
> Manuel Coutinho
>
>   
>> -----Original Message-----
>> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
>> Sent: Wednesday, May 27, 2009 12:50 AM
>> To: Manuel Coutinho
>> Cc: rtems-users at rtems.com
>> Subject: Re: Semaphore release - not owner of resource return
>>
>> 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
>>>
>>>       
>
>
>