Yield to specific thread?

[Tadeus Prastowo]

Based on my observation with the attached C program (please read the
comments for usage instruction and note that it requires root
privilege to use the POSIX real-time scheduling policy) when compiled
by defining or not defining the macro UNICORE, the priority support
works with glibc at least in Ubuntu 16.04 provided that the process is
not allowed to migrate to another processor core.

-- 
Best regards,
Tadeus

On Tue, May 25, 2021 at 8:58 PM Adhemerval Zanella via Libc-help
<libc-help@sourceware.org> wrote:
>
> 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
> >>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multicore-condvar.c
Type: text/x-csrc
Size: 4172 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-help/attachments/20210526/baf1a800/attachment-0001.bin>