From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward101o.mail.yandex.net (forward101o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::601]) by sourceware.org (Postfix) with ESMTPS id BA8EB3959CB6 for ; Thu, 20 May 2021 11:20:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BA8EB3959CB6 Received: from sas1-f446987054ad.qloud-c.yandex.net (sas1-f446987054ad.qloud-c.yandex.net [IPv6:2a02:6b8:c08:bf8a:0:640:f446:9870]) by forward101o.mail.yandex.net (Yandex) with ESMTP id B68CE3C004BD; Thu, 20 May 2021 14:20:41 +0300 (MSK) Received: from sas8-6bf5c5d991b2.qloud-c.yandex.net (sas8-6bf5c5d991b2.qloud-c.yandex.net [2a02:6b8:c1b:2a1f:0:640:6bf5:c5d9]) by sas1-f446987054ad.qloud-c.yandex.net (mxback/Yandex) with ESMTP id RbaO3b4tO4-KfKuBfAD; Thu, 20 May 2021 14:20:41 +0300 Received: by sas8-6bf5c5d991b2.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id XL2HP9cuml-KeK8wFvT; Thu, 20 May 2021 14:20:40 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Message-ID: <75365b7da217aab24c686e18399bc017aa6c9ac7.camel@yandex.ru> Subject: Re: Yield to specific thread? From: Konstantin Kharlamov To: Alexandre Bique , Florian Weimer Cc: Alexandre Bique via Libc-help Date: Thu, 20 May 2021 14:20:40 +0300 In-Reply-To: References: <877djtsm5h.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, 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: Thu, 20 May 2021 11:20:46 -0000 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 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