Semaphore release - not owner of resource return

[Manuel Coutinho]

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...)

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).

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
> >