This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/12674] sem_post/sem_wait race causing sem_post to return EINVAL
- From: "lopresti at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Thu, 4 Aug 2011 04:49:37 +0000
- Subject: [Bug nptl/12674] sem_post/sem_wait race causing sem_post to return EINVAL
- Auto-submitted: auto-generated
- References: <bug-12674-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=12674
Pat <lopresti at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lopresti at gmail dot com
--- Comment #6 from Pat <lopresti at gmail dot com> 2011-08-04 04:48:18 UTC ---
Ulrich does not understand your question because he is assuming you are an
idiot.
In particular, he is not reading your bug report carefully enough to recognize
that the behavior you have identified is a fundamental race rendering
semaphores useless.
It is a pretty simple question, really. Given a semaphore initialized to zero,
one thread that makes one call to sem_wait, and another that makes one call to
sem_post. Which thread can safely destroy the semaphore?
Obviously, the thread calling sem_post cannot destroy the semaphore because it
cannot know that sem_wait has returned.
You have shown that the one calling sem_wait cannot destroy it either because
of this broken implementation.
So neither thread can destroy the semaphore without adding some additional
synchronization mechanism. Ulrich says the behavior is not broken, which as
you rightly point out is ludicrous. But that's Ulrich for you.
--
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.