Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 26 May 2022 10:13:29 -0700 | Subject | Re: [GIT PULL] printk for 5.19 |
| |
On Thu, May 26, 2022 at 5:09 AM Petr Mladek <pmladek@suse.com> wrote: > > Yeah, it is a shame. I have met code with exclusive waiters only once, > 8 years ago and completely forgot about it.
Yeah, the exclusive waiters thing is quite unusual, and not a normal pattern.
It's basically only used for a very few performance-critical cases where the "multiple readers, but only one writer should wake things up" can happen.
And it's rare. It's things like "accept()" on a socket - where it's common to have a lot of threads waiting for a new connection, but you don't want to wake them all just because one new connection comes in, because only one of them will successfully take it.
There are not very many patterns like that where you have that "many people waiting for the same thing, only one will get it". It happens for socket readers (kind of like accept, but for the "UDP packet with command comes in"), or with things like pipes (which people use for similar things and distribute work to potentially lots of threads through a pipe).
So the common pattern tends to be "some event that gets a threaded server using one thread to complete", but there just aren't that many of those cases.
It _could_ also be used for things like locking (ie think "lock release wakes up waiter"), but I think all our lock primitives end up doing their wakeup routines at a lower level (ie using "wake_up_process()" directly) so those don't actually use it.
End result: the exclusive waiters are an important case, but they are rare - and thus the "all()" version of wakeup is also quite rare.
Linus
| |