This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #3 from Don Hatch <dhatch at ilm dot com> 2011-04-19 00:04:29 UTC ---
Upon further reading,
I see that the pthread_mutex_destroy man page
and the pthread_cond_destroy man page
both explicitly say that doing the analogous thing
to a mutex or condition variable is legal.

>From the same pthread_mutex_destroy man page
that I quoted earlier (from man-pages-2.39-12.el5):
"A mutex can be destroyed immediately after it is unlocked. For example,
consider the following code: [...]  In this case obj is reference counted and
obj_done() is called whenever a reference to the object is dropped. 
Implementations are required  to allow an object to be destroyed and freed and
potentially unmapped (for example, lines A and B) immediately after the object
is unlocked  (line C)."

>From the same pthread_cond_destroy man page
that I quoted earlier (from man-pages-2.39-12.el5):
"A condition variable can be destroyed immediately after all the threads that
are blocked on it are awakened. For example, consider the  following code:
[...] In  this  example,  the  condition variable and its list element may be
freed (line B) immediately after all threads waiting for it  are  awakened
(line A), since the mutex and the code ensure that no other thread can touch
the element to be deleted.

So if it's really the case that
posix semaphores don't provide the same guarantee
(or even if the spec says they do but the current implementation doesn't),
I think we can get that guarantee by implementing our own semaphores
in terms of mutexes and/or condition variables
(that is assuming the implementation of mutexes and condition variables
really does conform to the above quoted passages).

-- 
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]