From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) by sourceware.org (Postfix) with ESMTPS id 79BEB385702D for ; Wed, 26 May 2021 14:09:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 79BEB385702D Received: by mail-ua1-x92a.google.com with SMTP id f20so842089uax.6 for ; Wed, 26 May 2021 07:09:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Ex0s1QAisXXtHIbyb37afU4QtTm0bJ4HRvngDOxzulA=; b=gIhOgeG+z6iPpJlUC4Hxi8swcY/ivpMqPLcwuAYrB+SQuzW40KtUGXvPcTvd8anfiL 07UV+R34sM2lXpUbvh3uRK2fwnPVH1ojYcUEuBTgWEYbNCzLFLZ0nmYw8SNBzyI55kfU QPpAVTGxhoO8fSTmHZbJPBMnX30/8WRFNwxJWdtpx3V/v5km18KeMZLLdX+C3UzGRwej dxaFxBPX1R6YfwJn4at/d4GQbXLOk6qBZ/nPPnE9PqhWJqllsICpAvIbA2XEXZxmju5s Uel+qISEzOzxGvKN70Rz5NlyZwbQd2xJ5RN4xFruJKG+EhtI69NyqyIg6r/+Mjhm9KAM qHIA== X-Gm-Message-State: AOAM532/XZKNz7irW+hijGwdg3flM4K7fWSdi9GtqparIKV6l8zX+1Cc KTY0gh1ZyEY6kZWrEwnRDWsa0ie/SUSClckn9NdkWMJnk78= X-Google-Smtp-Source: ABdhPJyPhyoXRisuTg1L+GwgV1C1TQU4Ymdii3gyeTZ/KqxCOKLEYAc4ErR0zyEPQyqSVqst5iJvjkfWA7yn889zHjY= X-Received: by 2002:ab0:d8f:: with SMTP id i15mr13681819uak.104.1622038158007; Wed, 26 May 2021 07:09:18 -0700 (PDT) MIME-Version: 1.0 References: <877djtsm5h.fsf@oldenburg.str.redhat.com> <75365b7da217aab24c686e18399bc017aa6c9ac7.camel@yandex.ru> <7eb8d574-45c0-32d8-2b9d-c719535fd246@linaro.org> In-Reply-To: <7eb8d574-45c0-32d8-2b9d-c719535fd246@linaro.org> From: Alexandre Bique Date: Wed, 26 May 2021 16:09:01 +0200 Message-ID: Subject: Re: Yield to specific thread? To: Adhemerval Zanella Cc: Konstantin Kharlamov , Florian Weimer , Alexandre Bique via Libc-help Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2021 14:09:20 -0000 Thank you, this is very interesting! Alexandre Bique On Tue, May 25, 2021 at 8:21 PM Adhemerval Zanella 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 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 w= rote: > >>>> > >>>> * 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 u= p > >>>> 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 usin= g sched_yield() for the wrong reasons=C2=B9, 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 act= ively 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 lo= t of loads don't). > >>> > >>> But that's not "sched_yield()" - that's something different. It's gen= erally something like std::mutex, pthread_mutex_lock(), or perhaps a tuned = thing that uses an OS-specific facility like "futex", where you do the nonb= locking (and non-contended) case in user space using a shared memory locati= on, but when you get contention you tell the OS what you're waiting for (an= d what you're waking up). > >> > >> > >> 1: https://www.realworldtech.com/forum/?threadid=3D189711&curpostid=3D= 189752 > >>