All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Dmitry Vyukov <dvyukov@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH RFC] locking: Add volatile to arch_spinlock_t structures
Date: Thu, 4 Dec 2014 14:06:57 -0800	[thread overview]
Message-ID: <20141204220657.GB25340@linux.vnet.ibm.com> (raw)
In-Reply-To: <20141204214546.76b7b7cd@lxorguk.ukuu.org.uk>

On Thu, Dec 04, 2014 at 09:45:46PM +0000, One Thousand Gnomes wrote:
> > anywhere in that translation unit.  After all, any non-static function
> > in that translation unit might be called from some other translation
> > unit that -did- use locking or whatever.
> > 
> > I will let you know how it goes.  ;-)
> 
> It breaks DEC10 ;-)

To say nothing of CDC 6600 systems lacking the compare-move unit.  ;-)

> If there is kickback over things like optimisation perhaps the gcc
> maintainers could at least consider something like
> 
> 	int __attribute((threadsafe)) fred;
> 
> ??

Not needed for recent gcc versions -- both the C11 and C++11 standards
require that different threads be permitted to independently access
different variables, where "different" means "no bits of the two variables
residing in the same byte".  From what I can see, this would mean that
a conforming pre-EV56 Alpha C11 compiler would need to use LDL_L and
STL_C to carry out 8-bit and 16-bit stores.  ;-)

							Thanx, Paul

      reply	other threads:[~2014-12-04 22:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-04  6:20 [PATCH RFC] locking: Add volatile to arch_spinlock_t structures Paul E. McKenney
     [not found] ` <CA+55aFzn-6asfWHB8SAvz4GJWz7uEriujgVLfaqoo_VPtNBLuA@mail.gmail.com>
2014-12-04  6:57   ` Paul E. McKenney
     [not found]   ` <CA+55aFxGCxQNE4HzRP_Uk2FmFDn_+Hfm6GBz75S+5+SDeODVJQ@mail.gmail.com>
2014-12-04  7:02     ` Paul E. McKenney
2014-12-04 18:02       ` Linus Torvalds
2014-12-04 18:36         ` Paul E. McKenney
2014-12-04 19:18           ` Linus Torvalds
2014-12-04 20:00             ` Paul E. McKenney
2014-12-04 20:12               ` Paul E. McKenney
2014-12-04 21:45           ` One Thousand Gnomes
2014-12-04 22:06             ` Paul E. McKenney [this message]

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=20141204220657.GB25340@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=dave@stgolabs.net \
    --cc=dvyukov@google.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.