Semaphore release - not owner of resource return

[Manuel Coutinho]

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

 

Thanks

Kind Regards

Manuel Coutinho

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20090526/5fa0a134/attachment.html>