Re: Yield to specific thread?

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

I think you will need a conditional variable with a priority support.
Unfortunately POSIX requirements makes hard to provide it on glibc,

There is a project that aims to provide it [1] and I think it would
fit better in the scenarios you described: you setup a conditional
variable on a shared memory between the two processes A and B, you
setup B with higher priority than A, and when A produces a request
the condvar wakeup event will wake the highest priority waiters
(in the case B).

This library uses the FUTEX_WAIT_REQUEUE_PI futex operations with a
different (and I think non-POSIX conformant) conditional variable
implementation.

[1] https://github.com/dvhart/librtpi 

On 20/05/2021 08:54, Alexandre Bique via Libc-help wrote:
> 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
>>