From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) by sourceware.org (Postfix) with ESMTPS id D19E63858038 for ; Tue, 25 May 2021 18:21:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D19E63858038 Received: by mail-qv1-xf2b.google.com with SMTP id eb9so16514895qvb.6 for ; Tue, 25 May 2021 11:21:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2B/CxP7syZU4Dwt2Mih3YNjSgaJF1NtNX9TvrYhgpFg=; b=ejx4fiLRLyoLBQriOU2g+BjYB60AudXVpgYaexs9dL0ZyRM4kDBXaWMHLnB3y/zC6y 2W97XErvUAAwslUIMUYTNVw4J4nUjFTOeQd6PjItzz4iOpLbg6/aCuWKBS2gKqXFYSGc 3xjaIW2tIsvNP36PiFr9x8vROlZrG3gTWFxAWZ84vTnrw9DzeQNnFAyugkWYJEJQvQTI ASV5VNbK81no7gyC1msGUGyHRU7oEb11KZTtU2ylqL0RtjPutRwQj6eEQy7A8pNO2CcX yTwPLeqq/m2lBqV8TiMYUMnKm/QOTTvIOcFR7OqEIaKu8zi6hYZutIEhp5RCzMmRcF56 xQ7g== X-Gm-Message-State: AOAM530vAFoJ19b7Glc5V0lCKZj4oOs22JzGb3snBTCMbUPBAOND1bxh JlBM1nMdzDYQg7Dap5iV0+dNAJ790IhWkQ== X-Google-Smtp-Source: ABdhPJxQ8t/cilCOyH3RalXn4lBoLYBNyvw/dTqc4jWmTTZhsjdvHZSX04IlwCOURBauWrbbrWIZrg== X-Received: by 2002:a05:6214:1083:: with SMTP id o3mr5658193qvr.9.1621966910212; Tue, 25 May 2021 11:21:50 -0700 (PDT) Received: from [192.168.1.4] ([177.194.37.86]) by smtp.gmail.com with ESMTPSA id p14sm13769036qki.27.2021.05.25.11.21.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 May 2021 11:21:49 -0700 (PDT) Subject: Re: Yield to specific thread? To: Alexandre Bique , Konstantin Kharlamov Cc: Florian Weimer , Alexandre Bique via Libc-help References: <877djtsm5h.fsf@oldenburg.str.redhat.com> <75365b7da217aab24c686e18399bc017aa6c9ac7.camel@yandex.ru> From: Adhemerval Zanella Message-ID: <7eb8d574-45c0-32d8-2b9d-c719535fd246@linaro.org> Date: Tue, 25 May 2021 15:21:46 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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: Tue, 25 May 2021 18:21:52 -0000 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 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 >>