Semaphore release - not owner of resource return

[Manuel Coutinho]

Ok :)

Now I understand: Simple binary semaphores cannot have priority inheritance
or ceiling.

But RTEMS is currently allowing this. A simple binary semaphore can be
created with one of priority protocols and the holder threads priority is
increased/decreased accordingly.

Suppose this is a bug of RTEMS then: do not allow creation of simple binary
semaphores with priority ceiling or priority inheritance protocols.

Regarding bug PR788, forget my previous suggestion. My mind was not good at
the time!
However, had another "solution":
  When a thread is deleted, all the semaphores it holds are set free. 

This is actually the same behavior as specified in ARINC 653.

Of course, some modifications have to be performed to accomplish this.
But is there any special reason not to implement this behavior (apart from
the O(n) complexity issue)?

Kind regards
Manuel Coutinho

 
> -----Original Message-----
> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
> Sent: Tuesday, July 07, 2009 1:03 PM
> To: Manuel Coutinho
> Cc: rtems-users at rtems.com
> Subject: Re: Semaphore release - not owner of resource return
> 
> 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
> >>>
> >>>
> >
> >
> >