[RTEMS Project] #3975: RTEMS 5 : sem_wait + sem_destroy behavior change

RTEMS trac trac at rtems.org
Thu May 7 13:02:57 UTC 2020


#3975: RTEMS 5 : sem_wait + sem_destroy behavior change
--------------------------+---------------------
 Reporter:  andrei.lupas  |       Owner:  (none)
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:
Component:  admin         |     Version:  5
 Severity:  normal        |  Resolution:
 Keywords:                |  Blocked By:
 Blocking:                |
--------------------------+---------------------

Comment (by Joel Sherrill):

 The current behavior is what is specified in the POSIX standard:

 https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/sem_destroy.html

 {{{
 [EBUSY]
 There are currently processes blocked on the semaphore.
 }}}

 It is a shame that the signature does not have an attribute structure,
 that would make it easy to at least add the behavior option at the API
 level. This signature does not give any room for change:

 {{{
 int sem_init(sem_t *sem, int pshared, unsigned value);
 }}}

 Adding a flush operation to the POSIX semaphores could be an option but
 sem_wait() is not defined to return any errno values which make sense for
 a flush. But if sem_flush_np() were added, then using another errno to
 indicate it was flushed by a non-portable (e.g. _np) method is at least an
 option.

 Another option is to add a sem_XXX_np method to set the "allow delete when
 blocked threads" internal attribute. In this case, the threads unblocked
 by deleting the semaphore could return EINVAL like other POSIX methods do
 when the object id is invalid.

 I'm just offering options within the space of the POSIX standard. The
 second seems like a cleaner direct solution to your problem. This is a
 counting semaphore and there is no concept of a "holder" as with a mutex.
 Besides threads waiting on a resource, do not hold the resource.

 Hoping others will chime in.

--
Ticket URL: <http://devel.rtems.org/ticket/3975#comment:1>
RTEMS Project <http://www.rtems.org/>
RTEMS Project


More information about the bugs mailing list