[snip]
> In principle that works. But one of things that's less nice with
> pthread_cond_wait is
> that you sometimes have a (most of the time) unnecessary schedule
> ping-pong, and with the
> approach above you always have this (due to ack).
Only vs. pthread_cond_broadcast. And if you're using that you probably
have some other performance issues anyway?
> And secondly if
> futex_up(&f, N) for N > 1
> relies on the chained wakeup in the kernels futex_up routine the
> broadcast may take a while to
> complete (the lowest priority waiter penalizes all others queued behind
> him). A semaphore simply is no full replacement for a waitqueue with
> wake_all.
Yes, we could have a "wake N" variant, which would be more efficient here.
Hope that clarifies,
Rusty.
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/