Received: by 10.223.164.202 with SMTP id h10csp264041wrb; Thu, 30 Nov 2017 09:57:58 -0800 (PST) X-Google-Smtp-Source: AGs4zMaBSgQWtcPQj6J5q4nWEf2oijQAIRbX7ejsRFGANICdadKrOQW0SCztWccFirthsTu0XIeG X-Received: by 10.98.135.138 with SMTP id i132mr7347071pfe.130.1512064678289; Thu, 30 Nov 2017 09:57:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512064678; cv=none; d=google.com; s=arc-20160816; b=BKGCyzpK6BPVMlgIMxcRFm8SXXT7YtucMX+Uv94o04sh8Y1XZAl53c6UfV5bmnmjVj kVGQWNnOfdZ9nuzyR8x+9nNGhLYe9iuJSoR6FucV2UMn3vUzzU2dBZ7QMRnnoF6akdV6 iwmMecm/X3m+CfKd7EjXVCJwByjYy3qADDlvb6tQzEsd8ROmePyoxBtZzf3Q2S44suSz GYr/v0QZb31Pp4pVmt3zn50UwMM3k5KYKh4jxRq4BomwslXF4HdHn3pwWWRnKWgqCBQC +pQunLrOyUsAMcDN7zQouX4PF0bHtKUcGvWPok+kEg9Uy5hUFg/2mnQ0W4waku6BhPDm NOLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date:arc-authentication-results; bh=Q1Br4sqpKEiw/Vev35VO9wmaI1D4qMd99m/NvqGCwko=; b=fP4BQzLqAMb0dYQCax0wDGi7UOfHYLCXVfLnUC+rS5J8Tp0PBze1P/mziYBx5Mh9AP j4krHvyQEU0gFZOH+c4MNGKdiM8kpHhF3yPEid8IS4iPFWIC0bTGnwjOY07UmXPAbJub kPgh9LUY9keYO+EhZYm65Eucwq5Sz/JUOElm2gMKELB34bGj+eOJ19tw5Gcz6pOXQeoV 0IZi/s7/uITdnH6wlnDNIZlj6hL3WNxdY0xoymVIk0CwaBOJ3/py845kM1GCSKhkLy4s 5nAG3X8+isExaqRul0yQ7eT41yx4Cek+3JN5SJrUZ09gyio/x4gWVIFUbBVBUzDnFHQD 4Npg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=harvard.edu Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j2si3323100pgs.345.2017.11.30.09.57.44; Thu, 30 Nov 2017 09:57:58 -0800 (PST) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=harvard.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752290AbdK3R5P (ORCPT + 99 others); Thu, 30 Nov 2017 12:57:15 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:36022 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753980AbdK3R44 (ORCPT ); Thu, 30 Nov 2017 12:56:56 -0500 Received: (qmail 20217 invoked by uid 2102); 30 Nov 2017 12:56:55 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Nov 2017 12:56:55 -0500 Date: Thu, 30 Nov 2017 12:56:55 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: "Paul E. McKenney" cc: Will Deacon , Daniel Lustig , Peter Zijlstra , Andrea Parri , Luc Maranget , Jade Alglave , Boqun Feng , Nicholas Piggin , David Howells , Palmer Dabbelt , Kernel development list Subject: Re: Unlock-lock questions and the Linux Kernel Memory Model In-Reply-To: <20171130165435.GS3624@linux.vnet.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 30 Nov 2017, Paul E. McKenney wrote: > > > Will, are there plans to bring this sort of thing before the standards > > > committee? > > > > We discussed it, but rejected it mainly because of concerns that there could > > be RmW operations that don't necessarily have an order-inducing dependency > > in all scenarios. I think the case that was batted around was a saturating > > add implemented using cmpxchg. > > Ah, I do remember now, during the Toronto meeting, correct? > > So should we consider making LKMM make xchg act in a manner similar to > the other atomics, or would you prefer that we keep the current special > behavior? In fact, right now herd doesn't implement the dependencies. So "current special behavior" is ambiguous -- there's what herd currently does, and there's what one would expect it to do. (Incidentally, this should all be considered part of herd, rather than part of the LKMM. Although herd can simulate the memory model, they aren't the same thing.) Also, as Will says, some atomic operations have more than one possible implementation, with differing internal dependencies. Alan From 1585511363652956777@xxx Thu Nov 30 17:04:25 +0000 2017 X-GM-THRID: 1585255508732072548 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread