From: Peter Zijlstra
Sent: 08 June 2021 15:24
...
And if we're going to do a new interface, we ought to make one that can solve all these problems. Now, ideally glibc will bring forth some opinions, but if they don't want to play, we'll go back to the good old days of non-standard locking libraries.. we're halfway there already due to glibc not wanting to break with POSIX were we know POSIX was just dead wrong broken.
I had a problem with pthread_broadcast(). I've got multiple threads all bound to different cpu and I really do want to wake them all up at once. Now, I know they'll spin on the mutex for a bit - but that is soon released (the 'adaptive' spin is probably long enough).
But what actually happens (probably because of the way glibc is constrained by the futext system call) is: 1) The first thread is woken. 2) It's cpu comes out of sleep. 3) Once running it wakes the second thread. 4) It's cpu comes out of sleep. ... So you get a very slow ripple of the threads starting.
Worse still, if the thread can't be scheduled (eg because its cpu is running all the network stack softint code) then none of the later threads start running.
I've mitigated it by using a separate cv for each thread and looping to wake them all - but it shouldn't really be necessary.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)