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

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.


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