From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5794 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] private futex support Date: Fri, 8 Aug 2014 20:51:37 -0400 Message-ID: <20140809005137.GW1674@brightrain.aerifal.cx> References: <20140626184803.GA8845@brightrain.aerifal.cx> <20140808113857.1839babf@vostro> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1407545520 25838 80.91.229.3 (9 Aug 2014 00:52:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Aug 2014 00:52:00 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5799-gllmg-musl=m.gmane.org@lists.openwall.com Sat Aug 09 02:51:54 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XFusx-0000zF-N5 for gllmg-musl@plane.gmane.org; Sat, 09 Aug 2014 02:51:51 +0200 Original-Received: (qmail 16276 invoked by uid 550); 9 Aug 2014 00:51:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 16268 invoked from network); 9 Aug 2014 00:51:50 -0000 Content-Disposition: inline In-Reply-To: <20140808113857.1839babf@vostro> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5794 Archived-At: Just a quick explanation for some unexpected behavior you saw: On Fri, Aug 08, 2014 at 11:38:57AM +0300, Timo Teras wrote: > diff --git a/src/thread/pthread_cond_broadcast.c b/src/thread/pthread_cond_broadcast.c > index 0901daf..4327a0e 100644 > --- a/src/thread/pthread_cond_broadcast.c > +++ b/src/thread/pthread_cond_broadcast.c > @@ -27,7 +27,7 @@ int pthread_cond_broadcast(pthread_cond_t *c) > > /* Perform the futex requeue, waking one waiter unless we know > * that the calling thread holds the mutex. */ > - __syscall(SYS_futex, &c->_c_seq, FUTEX_REQUEUE, > + __syscall(SYS_futex, &c->_c_seq, 128 | FUTEX_REQUEUE, > !m->_m_type || (m->_m_lock&INT_MAX)!=__pthread_self()->tid, > INT_MAX, &m->_m_lock); > > diff --git a/src/thread/pthread_cond_timedwait.c b/src/thread/pthread_cond_timedwait.c > index 99d62cc..73c1781 100644 > --- a/src/thread/pthread_cond_timedwait.c > +++ b/src/thread/pthread_cond_timedwait.c > @@ -64,7 +64,7 @@ int pthread_cond_timedwait(pthread_cond_t *restrict c, pthread_mutex_t *restrict > > pthread_mutex_unlock(m); > > - do e = __timedwait(&c->_c_seq, seq, c->_c_clock, ts, cleanup, &cm, 0); > + do e = __timedwait(&c->_c_seq, seq, c->_c_clock, ts, cleanup, &cm, 1); > while (c->_c_seq == seq && (!e || e==EINTR)); > if (e == EINTR) e = 0; > > It seems that things worked even without these changes, but everything > was a lot slower. Not sure why. But the code sounds buggy anyway, Both the wait and wake (requeue) operations for this futex were wrongly shared rather than private, so since they still matched it makes sense that it didn't fail. The requeue was wrongly requeuing as shared on a mutex that would only receive a wake as private, but since there was only one waiter and the requeue requested one wake, I guess no requeue ever happened. Rich