On Tue, 27 Apr 1999 13:01:09 +0000, Richard Dynes <rdynes@varcom.com>
said:
> I'm interested in this too. Tony's point was my immediate thought:
> pthread_cond_signal is an obvious implementation of a solution to the
> 'thundering herd' problem. But it has apparently been discounted.
Not entirely, but it's not the perfect answer to the problem.
It's not perfect because it leaves the problem of selecting a thread
to wakeup to the application, and because it requires an explicit
API.
There are plenty of places where we want to wake up only one process
in the kernel --- connect(), for example, or read() from a pipe when
there's only enough data for one thread to get any data. Letting the
kernel decide which thread to wakeup is potentially much more
flexible, since it lets us wakeup a thread which was last scheduled on
a CPU which is now idle (and hence avoid the cache cost of having to
shift that thread's task-struct and stack between CPUs). The
application itself does not have enough information to make that sort
of a choice.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/