[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