Received: by 10.213.65.68 with SMTP id h4csp1096631imn; Wed, 4 Apr 2018 12:31:47 -0700 (PDT) X-Google-Smtp-Source: AIpwx48vyqlWnmsXOGijaxJdJPddTKO5irPbpqcu7DNFfR6pe2VxREy2G76kpiYeVZPy9wW4VEd6 X-Received: by 10.98.57.143 with SMTP id u15mr14822411pfj.79.1522870307684; Wed, 04 Apr 2018 12:31:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522870307; cv=none; d=google.com; s=arc-20160816; b=vCJB1vZMRJYqUoQ3teuJwXr50oEnMSawq1FOPaYBe9031AAYB2kNH0oBEdWwj/uDsW PR6xaWf1vk6pFUXjrJUHK9k3jN4NuwsGqZRZkDE3XzkMPUEkafuY6sISA32AoCcTUPGZ VS308XRz3L6r6XvGI7Dzai3d611NmJ2Y2sc08RzMXMzez8Kwn6rDyj2FXXsTTqv/7k/e nKrngdUdV1vnNPeL4yanqMR/NiOu5svCfZ5Tb4mDsdaP6b5Jw9g6Sm5/e4cOGaCjKwpt AISnF/L18B41x2MusKbzKh2j9C1QFQsu9RWlG1su5pLHcjMy31f2icV6C9Ni1F8Luf2o ZebQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:mime-version:user-agent:date:message-id:subject:to :organization:from:dkim-signature:arc-authentication-results; bh=NdcckgifoEotmi+syaEKTLYq0/kXJqI3YEYIE7NDUAo=; b=SZZq6dK0KNG0tNs9L9YkU/yLwZMBV8JCLRBfqYpa3/fqERnSXUyJDYX+yYp1yMErdZ lpKwed+q/W4kgKtlfqSkmO2/Rg6dYeqTr27JTqd5kXdpFFR+wraCROZAnIRdaKqQiF0V P7zqbCUzXgYBEtRVuAF0NvkKI+U99rGmUEVPnjsCCW/Yk9OHXqrXhjl5Vv6es7nmdWP5 c3/PRvH5n93Da2V98YjplIv4Z+ZpYs2fxStZSZGf1bKQGmzIQeSMDCphctE5rVXWSiYF 9qyrYaPPoz33XwmeENB1ONVWH1yxCA+m6HT5jpd1QXIbuD8i/4t+Ts4Dy+P/OTgQ1oel Nw6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=rvy+p842; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h13si2629724pfi.192.2018.04.04.12.31.33; Wed, 04 Apr 2018 12:31:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=rvy+p842; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752720AbeDDTaU (ORCPT + 99 others); Wed, 4 Apr 2018 15:30:20 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:42072 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752663AbeDDTaN (ORCPT ); Wed, 4 Apr 2018 15:30:13 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w34JIWps015055; Wed, 4 Apr 2018 19:29:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : subject : message-id : date : mime-version : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=NdcckgifoEotmi+syaEKTLYq0/kXJqI3YEYIE7NDUAo=; b=rvy+p842y9CDGJi2eYPmqz8A0bDoLDRJDqo6gm2G2J/CaVGQnKVb8f227dD5n0Ybm4kt raMFQLQqvzI49Fx9E88ABqD1vSMUgecyZospCeukYkfGTDMrSglcoDrFjkUC2SBpfLFL INcU81vmr3ManSedEpnwWLUWg7jd1GijwDRBtC0BjcHFX1V8VAqAQVsBRxsfN0R5ZKn0 RQDuPXEf9d36weBxwf6GJlGBZ4D9MYIasx07vAGrxHynCj33ROWRZMwZm6UW491XDOlo t5b0AJMPCFXOPlDakLlrY2xsLz+D++NjwIWEaR/tWjUNh96xBa3gHTbhycraG44gvzmf sw== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2h54rb81g0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 04 Apr 2018 19:29:41 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w34JTeB6022919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 4 Apr 2018 19:29:40 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w34JTd7V007908; Wed, 4 Apr 2018 19:29:39 GMT Received: from [10.152.33.180] (/10.152.33.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Apr 2018 12:29:39 -0700 From: Daniel Jordan Organization: Oracle To: stern@rowland.harvard.edu, parri.andrea@gmail.com, will.deacon@arm.com, peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr, paulmck@linux.vnet.ibm.com, akiyks@gmail.com, linux-kernel@vger.kernel.org, Steven Sistare , Pasha Tatashin Subject: Control dependency between prior load in while condition and later store? Message-ID: <087a5ca4-e788-60ee-9145-3a078781cf05@oracle.com> Date: Wed, 4 Apr 2018 15:29:33 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8853 signatures=668697 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=576 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804040189 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org A question for memory-barriers.txt aficionados. Is there a control dependency between the prior load of 'a' and the later store of 'c'?: while (READ_ONCE(a)); WRITE_ONCE(c, 1); I have my doubts because memory-barriers.txt doesn't talk much about loops and because of what that document says here: In addition, control dependencies apply only to the then-clause and else-clause of the if-statement in question. In particular, it does not necessarily apply to code following the if-statement: q = READ_ONCE(a); if (q) { WRITE_ONCE(b, 1); } else { WRITE_ONCE(b, 2); } WRITE_ONCE(c, 1); /* BUG: No ordering against the read from 'a'. */ It's not obvious to me how the then-clause/else-clause idea maps onto loops, but if we think of the example at the top like this... while (1) { if (!READ_ONCE(a)) { WRITE_ONCE(c, 1); break; } } ...then the dependent store is within the then-clause. Viewed this way, it seems there would be a control dependency between a and c. Is that right? Thanks, Daniel