From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id E42583857340 for ; Fri, 23 Sep 2022 13:34:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E42583857340 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oi1-x236.google.com with SMTP id d64so13423227oia.9 for ; Fri, 23 Sep 2022 06:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=Cc73sg7zH04KYg52p+Rb3undZvIVx9q0e+NJJPsyq9E=; b=jzsm1h+npFuO8tUrb97I5PbLxzD5L58IJj/RzFkZhEnd4h8XbcD+pl17/r/C8VGwqS 9FlLegH3mCTFwwRcRKRG8SGBh499Tts2Zd2te/4IEj8A1U+kPBOHb6PM5yss6IdIZdq8 3I75LEIuMWK6yT7FrSkkNrkYVoY152DBcSeTGgke4qh2uAMUTTWG03YZeG+h+dxxKbAS n/UhRGRof0di7DFk2eZQDomltLXDOaiAZfP8bnxpHPzxWh+C+RoEAv2o1CiaCtHhrmAG cyEX2Z2jrwl+rmIAgNm29G5N9rmW6bD4f8WhOG1XvbccTLRvp/6De/qCfxFsz0ZEvRA8 w39w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=Cc73sg7zH04KYg52p+Rb3undZvIVx9q0e+NJJPsyq9E=; b=4R6GS0RaLV2rX53r5LNHvYul3oRKswmEKWFD0jc86OKZeGBAEXc1+tVWoQz8knhxPX JD4pTWTyOEzobquViHLqoTu+FhOhux2XWoIU+ifXBEaheOBqq7eFW2dK6l57orJDuHkJ DKST/ifBtvsx/GB0p2gyi3Kj4ehK1L0FTESQmYraF1XZAnRthId4BnWihSeZOKJxnNC9 2h1hD7u9ip5+QYsfOqtyzp3QlrzJGPDUZInbYxeG3aLEWK2p+YmGLAU8RypbsPp0jYwy A13B3VzpSNpe6O5xUvTs5XFpU3WgMsgyIwjxF0JBls9ub7zuO+8r3KaoAqxzXqHK1Eib 91xA== X-Gm-Message-State: ACrzQf01hzDcSW7r5oagIaicAOg9jMU2vZ4bQac7ypkT3DwofLcTfNE6 yIhXkmXV78mvOdKVvnHtwYjFjYJPJBsioq9X X-Google-Smtp-Source: AMsMyM4CHRRgVgD6BhiOIfQjHAEsBb9hMkmtM+Hg5a2Ld0nzpLHQY+hASl7vc8LINRZcN2SdGEizyw== X-Received: by 2002:a05:6808:211d:b0:34f:e0fc:6e6e with SMTP id r29-20020a056808211d00b0034fe0fc6e6emr9117801oiw.8.1663940091257; Fri, 23 Sep 2022 06:34:51 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:c266:202e:f71c:c0e7:6b4e? ([2804:1b3:a7c1:c266:202e:f71c:c0e7:6b4e]) by smtp.gmail.com with ESMTPSA id r7-20020a056870e98700b0012c8f0d1f85sm4681323oao.17.2022.09.23.06.34.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Sep 2022 06:34:50 -0700 (PDT) Message-ID: <4f9cfb76-5d9f-7d10-3e28-e9c740bfe722@linaro.org> Date: Fri, 23 Sep 2022 10:34:49 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PATCH] Use C11 atomics instead of atomic_and/or Content-Language: en-US To: Wilco Dijkstra , 'GNU C Library' References: <32dd1e65-c065-99fa-4c49-d0612f1ef9e3@linaro.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.1 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 22/09/22 11:06, Wilco Dijkstra wrote: > Hi Adhemerval, > >> LGTM, the current atomic_or and atomic_and have acquire semantic already.  What >> I am not not sure if if we need to use release MO on start_thread, since the >> idea is to synchronize with the locking on pthread_mutex_lock. > > Indeed, it is not clear what is being synchronized with the FUTEX_OWNER_DIED > flag. However it is being used in a lock, so I kept the implied acquire MO of the > old atomics. If it is simply a flag that does not affect locking and the data > protected by the lock, then relaxed MO would be correct. However that requires > detective work to try to reverse engineer the intended implementation... I tried to check with kernel robust implementation, but this specific code is a fallback that should be handled by the kernel. It currently used on very specific cases (qemu and some old architectures that do not support set_robust_list) so I think we reevaluate it later.