From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 7D7853858400 for ; Wed, 5 Jan 2022 13:07:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7D7853858400 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 205CJxeQ030275; Wed, 5 Jan 2022 13:07:13 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3dcp2qy9h4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Jan 2022 13:07:13 +0000 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 205CeBnx013303; Wed, 5 Jan 2022 13:07:13 GMT Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0a-001b2d01.pphosted.com with ESMTP id 3dcp2qy9gq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Jan 2022 13:07:13 +0000 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 205D4oFw019038; Wed, 5 Jan 2022 13:07:12 GMT Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by ppma05wdc.us.ibm.com with ESMTP id 3daekb60yw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Jan 2022 13:07:12 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 205D7BH214811632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 5 Jan 2022 13:07:11 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 44FD8AE06A; Wed, 5 Jan 2022 13:07:11 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A1EFAAE068; Wed, 5 Jan 2022 13:07:10 +0000 (GMT) Received: from linux.ibm.com (unknown [9.160.188.26]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 5 Jan 2022 13:07:10 +0000 (GMT) From: Tulio Magno Quites Machado Filho To: Florian Weimer , libc-alpha@sourceware.org Cc: gcc-help@gcc.gnu.org, "Paul E. McKenney" Subject: Re: Help needed for glibc software transaction memory algorithm In-Reply-To: <87v8yzfv3u.fsf@oldenburg.str.redhat.com> References: <87v8yzfv3u.fsf@oldenburg.str.redhat.com> User-Agent: Notmuch/0.34.1 (http://notmuchmail.org) Emacs/27.2 (x86_64-redhat-linux-gnu) Date: Wed, 05 Jan 2022 10:07:09 -0300 Message-ID: <875yqy72ma.fsf@linux.ibm.com> Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-GUID: jE5JyOJsZ06brVbzlMwe9gQYqMTZqjBW X-Proofpoint-ORIG-GUID: hDwbJSsag3kfQRjrR3Vz2lc_LyIRxPrc X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-01-05_03,2022-01-04_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 priorityscore=1501 impostorscore=0 suspectscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 spamscore=0 adultscore=0 lowpriorityscore=0 clxscore=1011 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2201050088 X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2022 13:07:15 -0000 Florian Weimer via Libc-alpha writes: > To fix this, I think it is sufficient to add a release fence just before > the second version load in the reader. However, from a C memory model > perspective, I don't quite see what this fence would synchronize > with. AFAIU, it would synchronize with the previous relaxed load as if it were a release operation. Quoting N2731: A release fence A synchronizes with an atomic operation B that performs an acquire operation on an atomic object M if there exists an atomic operation X such that *X is sequenced before A*, X modifies M , and B reads the value written by X or a value written by any side effect in the hypothetical release sequence X would head if it were a release operation. Where: - X is the read of the STM-protected data; - B is the load of the counter for a second time; Notice that I fixed a typo in the original text that says "A is sequenced before X". Which is impossible because we would end up with: Fence A Operation X Operation B Source: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2731.pdf > And of course once there is one concurrency bug, there might > be others as well. Do I need to change the writer to use > acquire-release MO for the version updates? I don't think this is necessary. -- Tulio Magno