From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26487 invoked by alias); 10 Jun 2011 17:57:40 -0000 Received: (qmail 26480 invoked by uid 22791); 10 Jun 2011 17:57:40 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 10 Jun 2011 17:57:26 +0000 From: "martin at lispworks dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug nptl/12875] New: pthread_cond_timedwait can steal the wakeup of slower thread in pthread_cond_wait X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: martin at lispworks dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Fri, 10 Jun 2011 17:57:00 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2011-06/txt/msg00037.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=12875 Summary: pthread_cond_timedwait can steal the wakeup of slower thread in pthread_cond_wait Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: nptl AssignedTo: drepper.fsp@gmail.com ReportedBy: martin@lispworks.com Created attachment 5787 --> http://sourceware.org/bugzilla/attachment.cgi?id=5787 Example source code According to the definition of pthread_cond_signal, it should only unblock threads that are blocked at the time it is called. The attached example demonstrates a bug in pthread_cond_timedwait that can allow it to "steal" the signal from a thread that was blocked in pthread_cond_wait when pthread_cond_signal was called, even though pthread_cond_timedwait was called after pthread_cond_signal. This was tested on an Intel Core i7 970 CPU (6 cores, 12 threads) running Fedora 14 x86_64 with the master branch of glibc from 2011-06-10 and also with older releases. There is no easy way to repeat this, because it depends very much on the timing of the threads, so I've had to cheat by using pthread_kill to artificially delay the thread that called pthread_cond_wait (cs_ptA). The expected output of the program is A waits cs_timewaster starts B signals cs_delaywaster starts C waits D waits B signals C wakes D wakes with ETIMEDOUT cs_delaywaster ends A wakes Note that D wakes with ETIMEDOUT and A wakes afterwards. Often the program hangs after outputing A waits cs_timewaster starts B signals cs_delaywaster starts C waits D waits B signals C wakes D wakes with code 0 cs_delaywaster ends Note that D wakes with code 0 and A never wakes. The calls to usleep in the example are such that the first signal from thread B should cause thread A to wake and second signal should cause thread C to wake. Thread D should wake on the timeout. I think the problem is that if thread A wakes from the futex but doesn't execute the rest of pthread_cond_wait quickly enough (e.g. because the signal handler cs_delaywaster runs), then thread D can steal the wakeup when its futex returns on the timeout. -- 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.