[Bug nptl/12674] sem_post/sem_wait race causing sem_post to return EINVAL

["dhatch at ilm dot com" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12674

--- Comment #2 from Don Hatch <dhatch at ilm dot com> 2011-04-18 19:25:40 UTC ---
(In reply to comment #1)
> Why would this at all be a bug?  The fact that the sem_wait succeeds doesn't
> indicate at all that the semaphore is unused and destroying an unused semaphore
> is of course completely illegal.  Your code is wrong in assuming what it does. 
> You have to wait for the sem_post call to also return before destroying the
> semaphore.

Hi Ulrich,
Thanks for looking at this.

We're not completely confident that this usage is legal...
but we're not convinced yet that it's illegal either.

In our program, the sem_post itself is intended to indicate to the waiting
thread that it's safe to destroy the semaphore
(and, in a real program, to destroy some associated resource as well).
If the waiter thread has to wait for the sem_post call to return, as you say,
what would be a mechanism for doing that?  Another semaphore?
Would you agree that then either the semaphore,
or the semaphore-that-protects-the-semaphore, etc.
would need to be an object that persists significantly longer
than the resources being protected?
Maybe this is a reasonable or necessary
restriction, but it's a significant one,
and if it's intentional, it would be very helpful to have it documented.

Various manual pages I've seen which come close to mentioning it,
and which seem to me to (weakly) to imply my usage is legal, are:

sem_destroy man page from my RHEL5.3 distribution (man-pages-2.39-12.el5):
"Destroying  a  semaphore  that other processes or threads are currently
blocked on (in sem_wait(3)) produces undefined behaviour."
(doesn't mention sem_post, but it seems like this would be
the appropriate place to mention it if it's illegal,
and the fact that it doesn't mention it seems to imply it's legal).

Various other sem_destroy man pages, such as the one from
Open Group Base Specifications
(http://pubs.opengroup.org/onlinepubs/009695399/functions/sem_destroy.html)
say:
"It is safe to destroy an initialized semaphore upon which no threads are
currently blocked. The effect of destroying a semaphore upon which other
threads are currently blocked is undefined."
(the most literal reading of this implies that in my case,
it's safe to destroy the semaphore, since it's certainly
the case that no threads are currently blocked on it).

The pthread_mutex_destroy man page (from man-pages-2.39-12.el5):
"It shall be safe to destroy an  initialized  mutex  that  is  unlocked.
Attempting to destroy a locked mutex results in undefined behavior."
(again, a literal reading of this implies my usage is safe.
of course this is talking about mutexes, not semaphores,
but I imagine all the same limitations and considerations apply).

The pthread_cond_destroy man page (from man-pages-2.39-12.el5):
"It shall be safe to destroy  an  initialized  condition  variable  upon which 
no threads are currently blocked. Attempting to destroy a condition variable
upon which other threads are currently blocked results in undefined behavior."
(my comment on this would be the same as for pthread_mutex above)

Unfortunately I don't have access to the pthreads standard...
does it take a definite position on this?  If it does,
it would be great to have that clarification added to all these man pages
so that future programmers will have no doubts about it.

Thanks,
Don Hatch

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.