Date: Mon, 3 Oct 2011 23:53:53 +0200 From: Maxime Henrion <mux@FreeBSD.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: Adrian Chadd <adrian@freebsd.org>, freebsd-current@freebsd.org, Alexander Zagrebin <alexz@visp.ru> Subject: Re: cvsup broken on amd64? Message-ID: <CAM=sVkfSJ-KaVwRTjQ1711d=gJ0evDUEz2A6Yy8e4Wrma7zy-A@mail.gmail.com> In-Reply-To: <20111003213024.GA42715@stack.nl> References: <20110908221356.Horde.MFEsZ6Qd9PdOaSIEaid2X_A@avocado.salatschuessel.net> <4E692F87.5010708@sentex.net> <20110909073305.Horde.oi-EGaQd9PdOaaURAsTRVJk@avocado.salatschuessel.net> <4E6A076D.7040309@wintek.com> <EA16DA2E96DD411C8C8A7EC81E034162@vosz.local> <CAJ-VmonzwUVEHgzOU1QAY7hGKwLn6Dx2RxTaE4bEn0m4eoee3w@mail.gmail.com> <EBF2A1324C994063B9EAD7090563EC36@vosz.local> <CAJ-VmokwiVYHDymaOVcKQEbJ_ohjN8XOa8Q11e5GQ-mf1Hqt7g@mail.gmail.com> <CAM=sVkdXy7p52Skud1D1MyhcJxPWVkLzMihCegGC72BvH5zq5Q@mail.gmail.com> <20111003213024.GA42715@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 3, 2011 at 11:30 PM, Jilles Tjoelker <jilles@stack.nl> wrote:
> On Mon, Oct 03, 2011 at 06:15:41PM +0200, Maxime Henrion wrote:
>> Knowing all that, what's happening seems quite clear. If
>> fixups_close() is called while there was still fixup requests pending,
>> those should be processed by the detailer thread before it returns.
>> Subsequent fixups_get() call should continue returning pending items,
>> until there are no more entries in the queue _and_ the queue is
>> closed.
>
>> So, line 144 in fixups.c (in fixups_get()):
>
>> =A0 =A0 =A0 =A0 if (f->closed) {
>
>> should actually be:
>
>> =A0 =A0 =A0 =A0 if (f->closed && f->size =3D=3D 0) {
>
> That looks sensible.
>
>> The fact that this could even happen smells a bit weird to me though;
>> it means the detailer thread didn't get a chance to run between some
>> item was added to the queue (fixups_put() signals the detailer thread
>> via pthread_cond_signal()), and that it only runs now that the updater
>> queue has been closed. I wouldn't go as far as saying this is a bug,
>> but is it even valid for the pthread library to "coalesce" two
>> pthread_cond_signal() calls into one when the thread didn't get to run
>> since the first call was made? If so, then the above fix is perfectly
>> valid. If not, there is a deeper bug in the threading library, or in
>> the CVS mode code which I didn't write (but that seems far-fetched).
>
> The pthread library is free to "coalesce" pthread_cond_signal() calls
> like that. This is because a thread awakened by pthread_cond_signal()
> (or any other event) is not guaranteed to start running immediately and
> pthread_cond_signal() does nothing if there is no thread to wake up.
Great, that's a relief. I knew the pthread library was free to wake a
thread up even if it hadn't been signaled, which is why one always has
to call pthread_cond_wait() inside of a while() loop checking for the
condition, but wasn't sure about that particular scenario, so I'm glad
to hear a confirmation. Thanks!
Cheers,
Maxime
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM=sVkfSJ-KaVwRTjQ1711d=gJ0evDUEz2A6Yy8e4Wrma7zy-A>