[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Poor condvar performance

Hash: SHA1

Jamie Lokier wrote:

> cond_signal() would run through the list, calling
> futex_requeue2(entry_addr, 1, infinity) for each entry.

Why such a list?  Lists at userlevel are bad.  One of the aspects of the
current kernel interface which makes the userlevel code so robust is
that we don't have any lists except the list of all threads (or stacks).
 No lists for waiters, this was the big nightmare in LinuxThreads.

Fortunately it's not needed with your approach.

If the FUTEX_WAIT2 call would take the extra parameter, the value can be
stored somewhere on the thread's stack in the kernel (local variable).
Then if and only if the FUTEX_REQUEUE2 call is used, it is used in the
requeue operation.  The caller of FUTEX_REQUEUE2 need not know the
address.  It can be relied on that the waiter knows it.

Using FUTEX_REQUEUE2 to wake a thread which didn't use FUTEX_WAKE2 could
be considered a protocol violation.  It might also be possible to
consider this case as a simple FUTEX_WAKE.

> This isn't a great interface because you can't requeue2 to move a
> waiter a second time.  But it is fine for pshared condvars, I think.

It's actually usable for all condvars, not only shared.  This is
important, I really don't want to have too much difference in the code
paths for condvars.

If you can come up with a patch we can easily check the performance.

> (I did think of some other primitives, but the above two are the ones
> that seem like they could be implemented easily).

I've pretty sure there will be more interesting primitives we can think
of over time.

- -- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Version: GnuPG v1.2.3 (GNU/Linux)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]