Re: Multi-threaded performance progress

[Jens Gustedt <jens.gustedt@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 2489 bytes --]

Am Dienstag, den 26.08.2014, 15:05 -0400 schrieb Rich Felker:
> On Tue, Aug 26, 2014 at 08:30:39PM +0200, Jens Gustedt wrote:
> > Or do you mean that I should use an atomic store at the other end?
>
> Yes. With an atomic store at the other end, I think it could be
> correct, but I'd need to review it further to be sure.

ok, it shouldn't be difficult to use atomic ops, then.

> > > Note that the performance of the code in which you're trying to avoid
> > > the lock does not matter in the slightest except when a race happens
> > > between a thread acting on cancellation or timeout and a signaler
> > > (since that's the only time it runs). I expect this is extremely rare,
> > > so unless we determine otherwise, I'd rather not add complexity here.
> > 
> > If we have a broadcaster working a long list of waiters, this might
> > still happen sufficiently often. And the "complexity" is hidden in the
> > execution pattern of the current version, where control and handling
> > of the list alternates between different threads, potentially as many
> > times as there are waiters in the list.
> 
> Does your code eliminate that all the time? If so it's more
> interesting. I'll look at it more.

Yes, it will be the signaling or broadcasting thread that will be
working on the integrity of the list while it is holding the lock. At
the end those that it detected to be leaving will be isolated list
items, those that are to be signaled form one consecutive list that is
detached from the cv, and the ones that remain (in the signaling case)
form a valid cv-with-list.

The only small gap that remains (and that annoys me) is the leaving
thread that sneaks in

 - marks itself as leaving before the end of the  the CS
 - only asks for _c_lock *after* the signaling thread has left its CS

This is all our problem of late access to the cv variable revisited,
but here it is condensed in a very narrow time frame. Both threads
must be active for this to happen, so my hope is that when both are
spinning for some time on the  c_lock for the waiter and on ref for
the signaler, none of them will "ever" be forced into a futex wait.

Jens

-- 
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]