Re: Yield to specific thread?

[Konstantin Kharlamov <hi-angel@yandex.ru>]

On Thu, 2021-05-20 at 13:09 +0200, Alexandre Bique via Libc-help wrote:
> On Thu, May 20, 2021 at 1:03 PM Florian Weimer <fweimer@redhat.com> wrote:
> > 
> > * Alexandre Bique via Libc-help:
> > 
> > > Ideally I'd like to do:
> > > A produces a request
> > > A sched_yield_to(B)
> > > B processes the request
> > > B sched_yield_to(A)
> > 
> > This looks like an application for a condition variable or perhaps a
> > barrier.  If there is just a single writer, the kernel should wake up
> > the desired thread.
> 
> I don't think conditions or barriers would solve the problem. Because
> they would just put the waiting threads on the wake up queue like the
> read() on the pipe would.

I assume it should work. I remember Torvalds ranting about people using sched_yield() for the wrong reasons¹, and he mentioned mutex (which apparently worked for you) as one of possible solutions. Quoting:

> Good locking simply needs to be more directed than what "sched_yield()" can ever give you outside of a UP system without caches. It needs to actively tell the system what you're yielding to (and optimally it would also tell the system about whether you care about fairness/latency or not - a lot of loads don't).
>
> But that's not "sched_yield()" - that's something different. It's generally something like std::mutex, pthread_mutex_lock(), or perhaps a tuned thing that uses an OS-specific facility like "futex", where you do the nonblocking (and non-contended) case in user space using a shared memory location, but when you get contention you tell the OS what you're waiting for (and what you're waking up).


1: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189752