Yield to specific thread?

[Alexandre Bique]

Oh I think I fixed it using 3 mutexes.
Alexandre Bique

On Thu, May 20, 2021 at 1:20 PM Konstantin Kharlamov <hi-angel@yandex.ru> wrote:
>
> 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
>