Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 Aug 2014 17:20:13 -0400
From: Rich Felker <>
Subject: Re: bug in pthread_cond_broadcast

On Tue, Aug 12, 2014 at 08:18:59PM +0200, Jens Gustedt wrote:
> Am Dienstag, den 12.08.2014, 13:19 -0400 schrieb Rich Felker:
> > Once broadcast returns (as observed by the thread which called
> > broadcast, or any thread that synchronizes with this thread after
> > broadcast returns), there are no waiters and it's valid to use a new
> > mutex with the cond var (or destroy it if it won't be used again).
> all the clients can only wakeup on holding their mutex, which in turn
> is only released by the main thread after it returns from the
> broadcast operation.
> so yes, the broadcast operation is synchronized with all other
> threads, that's the idea of this test

OK, thanks for clarifying. I'm still trying to understand where the
error in musl's accounting is happening -- I'd like to find a fix that
would be acceptable in the 1.0.x branch and make that fix before
possibly re-doing the cond var implementation (a fix which wouldn't be
suitable for backporting).


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.