From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 8/8] evtchn: add FIFO-based event channel hypercalls and port ops Date: Wed, 20 Mar 2013 16:15:09 +0000 Message-ID: References: <5149DBA2.8030701@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5149DBA2.8030701@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: David Vrabel , Tim Deegan Cc: "xen-devel@lists.xen.org" , Wei Liu , Jan Beulich , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On 20/03/2013 15:54, "David Vrabel" wrote: >>>> You might have to use an atomic_t or similar if the consumer might be >>>> confused by partial updates. >>> >>> I have assumed that reads and writes to 32-bit words are atomic on all >>> interesting architectures. >> >> True, but unless you explicitly tell it to, the compiler isn't required >> to update a 32-bit variable using 32-bit operations, or to avoid >> weird-looking intermediate values. It seems unlikely that it would do >> anything other than straightforwardly write the new value, but we've seen >> compilers do some unlikely things. :) > > Ok. Looks like I need to use write_atomic() to update the head in Xen. Yes, I introduced {read,write}_atomic() precisely to deal with this possibility. No doubt we are missing some places it ought to be used, but at least we fix them when we spot them and new code should make use of them. It also provides some form of documentation about memory locations involved in lock-free communication/synchronisation. -- Keir