From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 24534 invoked from network); 31 Mar 2020 15:05:45 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 31 Mar 2020 15:05:45 -0000 Received: (qmail 1632 invoked by uid 550); 31 Mar 2020 15:05:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1602 invoked from network); 31 Mar 2020 15:05:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncentric-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=hx6ARTmHLQja5L5cvi88FuAp/jqeRdt34GXVV0cZhuE=; b=J6GAqONMVnScGQwJrHJgMcY0E3YLLomL86nh5m9met3lFtdeeHXPl5ICneMj5fCMPr BDx32ymTGyilVgR2sfZJxLMFL7sa4YOsaci1bM+SQL37zFT3yOj/rXJtuHlKwJ3Qpwk6 NHc9Da1z+DuZfAWM2kfiCbF11o3qUs7IUsHe+DA72BCQMgAjq8AcYPwkR56zeNHYW5Pn 3Q0Awx42Zamni/HcW7QVPoDK0x7OraDHAsBgxsbR0qqmEKN+hNlRlRdwDw1y21w1MLFF 5R1LO/GKxhJJ1iVJu7qXIi4GGDizrEZk+237Fg3RixpPdZbZhP0ewtpvkG2wPxh2qAUk 9mnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=hx6ARTmHLQja5L5cvi88FuAp/jqeRdt34GXVV0cZhuE=; b=dmzK1P0kDDMbrOSw5XoiN61lganTq+zeHxKm0rjHezvOAC3GHkqweaUK0N3haeHyt5 eJv7dqAuTzwgIB29BBs8As9MLP6UVJtnHANtSeKSJuRqrhJtK4h8n20mrpzAlbQN7bx1 xU96MUm1JTwCDpMaPU/yCt3J2nWLQYcOSt0BfEJCQtKLKolLMzLUNzbr2ElkFJVvaVzp Ko6Ai87DNMDFjiwugpTrKeNepjwIuI3WxqZ4K42X20vdp/cq6NGq58/xkCAmjN3nl1c7 TT5hSg9Uh2QLhs2XLx3IsuOqbAyXp1VKGfx9Qg1xt8sd75sPF7b2GRxEnbt/3Sb0iQku mV1A== X-Gm-Message-State: ANhLgQ0+M/sYFF1GKCv/Opg3qrB6WvvSOFZdIKmsm95DKtXBDKEIzfFz UNlZ/QUKzxexpxtl65H0P4tjyIA64Wg= X-Google-Smtp-Source: ADFU+vubYAepmwk5UmZpVVfYtkNlYObj88CJC33XSNO2zpH3EthEX8ErfNdX4nu5ACLqR/virW2Kvg== X-Received: by 2002:adf:cd12:: with SMTP id w18mr20526185wrm.311.1585667129846; Tue, 31 Mar 2020 08:05:29 -0700 (PDT) From: Koen Vandeputte To: musl@lists.openwall.com Message-ID: <5a0db239-4121-8a70-832a-e43ce7632d8e@ncentric.com> Date: Tue, 31 Mar 2020 17:05:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: [musl] Simple question regarding read-write locks precedence Hi All, I've written a user app which make use of reader-writer locks. Topology is pretty simple: - 1 writer - 4 readers Writes only occur once in a while. Readers are heavy users of the lock. The default behavior in musl is Reader precedence. In my usecase, it means that a writer never aquires the lock causing writer starvation. Debugging nicely shows that readers also "jump over" the waiting writer as there is always at least 1 reader present in the critical section at any time. Going through the source code shows that there is no support for specifying lock attributes which give writers precedence over readers. Is there an update scheduled to add the required attribute types which allow writer precedence to avoid starvation? Thanks, Koen