From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx.kolabnow.com (mx.kolabnow.com [95.128.36.41]) by sourceware.org (Postfix) with ESMTPS id 8D08C393C84A; Mon, 1 Mar 2021 17:39:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8D08C393C84A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=appliantology.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=rodgert@appliantology.com Received: from localhost (unknown [127.0.0.1]) by ext-mx-out002.mykolab.com (Postfix) with ESMTP id F07D4A17; Mon, 1 Mar 2021 18:39:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kolabnow.com; h= message-id:references:in-reply-to:subject:subject:from:from:date :date:content-transfer-encoding:content-type:content-type :mime-version:received:received:received; s=dkim20160331; t= 1614620341; x=1616434742; bh=G8DHPliXbgcSIBRZcvyYOW9nh9+KgEcWPUy PA8lg3ig=; b=q3EgyAfrGgJIi73iPcERiXz8zOmiwVV+Oqkr7fNKibpJA+Cmjsi w9CE2yKlV+6FKS5mOAHnpdB43oS1Gm0hzxGcJZVS37rxnB38Azw4z0Nsl9UUaXos 5QXPftQorkYFRoEDzL2bmIJxbE4LLn7M5wBPiFIKSu9bdtc9Z+oiUsuO5sUw/unN 9lRXoXBX1/qEIzx6NimXW+nq3HyIRtDvHNBKWUWsmDTX/BavHbD4hKBfGxAVAcYy zLDkTQ4r/m64IQJSWrr4NzTlyZ9uAJP7RzU7EBmpjQKFZuTOxBFgF2Voeu0hH91x 4Ymhfy0mSC7v/bIsUGpJggNPYEDPC8rhd4xnQXS/nQ5vIObWDVO1UjtGgOqx5XBO +jBEcvVThK3af8/P4fXi/P7VeGH/SiSr7QvFVhtxxiuLTifjLiMw1UwJR5W88+xd tA40gg9vbiNMtwXzCWl1MPc2iMJGKrsckmrEX8T4n7tXnCgTP6drzlJ8Z9lmdFle 7KcaAoF0msg5OhhK0an6MLVGJze+KCsCyDNyZcrfyiNV68nnTHIpemXA7sBMNBaP Fu2KGVoleK2f4xF+1Hkp9Ob2j8m8XJ5C/YeCCjQcqXGV5+8SRpf2MRSlkEGBjSu+ Dgu0g3+NHoLQoAn2whuMnPaKb1DKSnvpeTMFFzQ2f4H0K6N2z48xhb10= X-Virus-Scanned: amavisd-new at mykolab.com X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, KAM_SHORT, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 Received: from mx.kolabnow.com ([127.0.0.1]) by localhost (ext-mx-out002.mykolab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qGFZrYtbwzi; Mon, 1 Mar 2021 18:39:01 +0100 (CET) Received: from int-mx001.mykolab.com (unknown [10.9.13.1]) by ext-mx-out002.mykolab.com (Postfix) with ESMTPS id 4577649A; Mon, 1 Mar 2021 18:39:01 +0100 (CET) Received: from int-subm001.mykolab.com (unknown [10.9.37.1]) by int-mx001.mykolab.com (Postfix) with ESMTPS id 8C9D5376; Mon, 1 Mar 2021 18:38:59 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 01 Mar 2021 09:38:58 -0800 From: Thomas Rodgers To: Thiago Macieira Cc: Hans-Peter Nilsson , libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH 4/5] barrier: use int instead of unsigned char for the phase state In-Reply-To: <2595163.O2iKbAuXug@tjmaciei-mobl1> References: <1968544.UC5HiB4uFJ@tjmaciei-mobl1> <20210226155937.621324-4-thiago.macieira@intel.com> <2595163.O2iKbAuXug@tjmaciei-mobl1> Message-ID: <45ba4dd479974325be5147e2ff5fa27d@appliantology.com> X-Sender: rodgert@appliantology.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2021 17:39:07 -0000 On 2021-03-01 09:24, Thiago Macieira via Libstdc++ wrote: > On Sunday, 28 February 2021 07:05:47 PST Hans-Peter Nilsson wrote: On > Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote: ints can be > used in futexes. chars can't. > Shouldn't that be an atomic type instead of a bare int then? > There are a couple of atomic_refs: > > using __atomic_phase_ref_t = std::__atomic_ref<__barrier_phase_t>; > using __atomic_phase_const_ref_t = std::__atomic_ref __barrier_phase_t>; > > And _M_phase, despite being non-atomic, is never accessed without the > atomic_ref, aside from the constructor. Both arrive() and wait() start > off by > creating the atomic_ref. If it's non-atomic, then how is wait() supposed to wait on it, atomically? > But I confess I don't understand this code sufficiently to say it is > correct. > I'm simply saying that waiting on unsigned chars will not use a futex, > at > least until https://lkml.org/lkml/2019/12/4/1373 is merged into the > kernel. And I am not disagreeing with that. I am, however saying, that I know this particular implementation (well the upstream one it is based on) has been extensively tested by the original author (ogiroux) including time on Summit. If we are going to start changing his design decisions (beyond the largely cosmetic, not algorithmic, ones that I have made as per Jonathan's request), they should be motivated by more than a 'well we feel int's would be better here because Futex' justification.