xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Keir Fraser <keir@xen.org>
To: David Vrabel <david.vrabel@citrix.com>, Tim Deegan <tim@xen.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH 8/8] evtchn: add FIFO-based event channel hypercalls and port ops
Date: Wed, 20 Mar 2013 16:15:09 +0000	[thread overview]
Message-ID: <CD6F910D.5EE7B%keir@xen.org> (raw)
In-Reply-To: <5149DBA2.8030701@citrix.com>

On 20/03/2013 15:54, "David Vrabel" <david.vrabel@citrix.com> 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

  reply	other threads:[~2013-03-20 16:15 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-19 21:00 [PATCH RFC 0/8] Xen: FIFO-based event channel ABI David Vrabel
2013-03-19 21:00 ` [PATCH 1/8] debug: remove some event channel info from the 'i' and 'q' debug keys David Vrabel
2013-03-19 21:00 ` [PATCH 2/8] evtchn: refactor low-level event channel port ops David Vrabel
2013-03-20 10:21   ` Jan Beulich
2013-03-20 13:37     ` David Vrabel
2013-03-20 10:24   ` Jan Beulich
2013-03-19 21:00 ` [PATCH 3/8] evtchn: add a hook to bind an event port to a VCPU David Vrabel
2013-03-19 21:00 ` [PATCH 4/8] evtchn: Dynamically allocate d->evtchn David Vrabel
2013-03-20 11:43   ` Wei Liu
2013-03-19 21:00 ` [PATCH 5/8] evtchn: use a per-domain variable for the max number of event channels David Vrabel
2013-03-20 10:27   ` Jan Beulich
2013-03-19 21:00 ` [PATCH 6/8] HACK! evtchn: increase number of buckets to support the FIFO ABI David Vrabel
2013-03-19 21:00 ` [PATCH 7/8] evtchn: add FIFO-based event channel ABI David Vrabel
2013-03-20 10:32   ` Jan Beulich
2013-03-20 13:38     ` David Vrabel
2013-03-19 21:00 ` [PATCH 8/8] evtchn: add FIFO-based event channel hypercalls and port ops David Vrabel
2013-03-20 10:47   ` Jan Beulich
2013-03-20 13:42     ` David Vrabel
2013-03-20 13:55       ` Jan Beulich
2013-03-20 14:23         ` Tim Deegan
2013-03-20 14:38           ` David Vrabel
2013-03-20 15:34             ` Tim Deegan
2013-03-20 15:54               ` David Vrabel
2013-03-20 16:15                 ` Keir Fraser [this message]
2013-03-20 13:50   ` Wei Liu
2013-03-19 21:15 ` [PATCH RFC 0/8] Xen: FIFO-based event channel ABI Keir Fraser
2013-03-20 10:15 ` Jan Beulich
  -- strict thread matches above, loose matches on Subject: below --
2013-08-09 18:08 [RFC PATCH " David Vrabel
2013-08-09 18:08 ` [PATCH 8/8] evtchn: add FIFO-based event channel hypercalls and port ops David Vrabel
2013-08-16 16:33   ` Wei Liu
2013-08-19 10:32     ` David Vrabel
2013-08-19 10:46       ` Wei Liu
2013-08-23 10:33   ` Jan Beulich
2013-08-23 11:00     ` David Vrabel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CD6F910D.5EE7B%keir@xen.org \
    --to=keir@xen.org \
    --cc=JBeulich@suse.com \
    --cc=david.vrabel@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).