On Tue, 2018-02-27 at 19:32 +, Ruslan Nikolaev wrote:
>
> > But we're not talking about that special case of 128b types here. The
> > majority of synchronization doesn't need more than machine word size.
> Then why do you worry about read-only access for 128b types? (it is a special
> case a
On Tue, 2018-02-27 at 17:29 +, Ruslan Nikolaev wrote:
>
>
> > Consider a producer-consumer relationship between two processes where
> > the producer doesn't want to wait for the consumer. For example, the
> > producer could be an application that's being traced, and the consumer
> > is a tra
On Tue, 2018-02-27 at 16:40 +, Simon Wright wrote:
> On 27 Feb 2018, at 12:56, Ruslan Nikolaev via gcc wrote:
> >
> > And all this mess to accommodate almost non-existent case when someone
> > wants to use atomic_load on read-only memory for wide types, in which no
> > good solution exists
On Tue, 2018-02-27 at 13:16 +, Ruslan Nikolaev via gcc wrote:
> > 3) Torvald pointed out further considerations such as users expecting
> > lock-free atomic loads to be faster than stores.
>
> Is it even true? Is it faster to use some global lock (implemented through
> RMW) than a single RMW
On Tue, 2018-02-27 at 13:04 +, Szabolcs Nagy wrote:
> the solutions is to add a language extension
I think this only needs a library interface, at least when we're just
considering the __atomic builtins. On the C/C++ level, it might amount
to just another atomic type, which only has a CAS how
On Tue, 2018-02-27 at 12:56 +, Ruslan Nikolaev via gcc wrote:
> But, of course, it is kind of annoying that double-width types (and that also
> includes potentially 64-bit on some 32-bit processors, e.g. i586 also has
> cmpxchg8b and no official way to read atomically otherwise) need special
On Mon, 2018-02-26 at 22:45 +, Ruslan Nikolaev via gcc wrote:
> Thanks, everyone, for the output, it is very useful. I am just proposing to
> consider the change unless there are clear roadblocks. (Either design choice
> is probably OK with respect to the standard formally speaking, but there
On Tue, 2018-02-27 at 10:22 +, Ramana Radhakrishnan wrote:
> The way to fix this in AArch64 if there is a
> guarantee from the standard that there are no problems with read-only
> locations is to implement the change in libatomic.
Even though the standard doesn't specify read-only memory, I t
On Mon, 2018-02-26 at 19:39 +, Ruslan Nikolaev via gcc wrote:
> Torvald, I definitely do not want to insist on this design choice, but it
> makes sense to at least seriuously consider it given the concerns I
> described. And especially because IFFUNC in libatomic already redirects to
> cmpxc
On Mon, 2018-02-26 at 18:55 +, Ruslan Nikolaev via gcc wrote:
> Torvald, thank you for your output. See my response below.
>
> On Monday, February 26, 2018 1:35 PM, Torvald Riegel
> wrote:
>
> > ... does not imply this latter statement. The statement you cited
On Mon, 2018-02-26 at 07:24 +, Ruslan Nikolaev via gcc wrote:
> Alexander,
> Thank you for your comments. Please see my response below. I definitely do
> not want to fight for or against this change in gcc, but there are definitely
> legitimate concerns to consider. I think, it would really
On Mon, 2018-02-26 at 08:50 +0300, Alexander Monakov wrote:
> > For these reasons, it may be a good idea if GCC folks reconsider past
> > decision. And just to clarify: if mcx16 (x86-64) is not specified during
> > compilation, it is totally OK to redirect to libatomic, and there make the
> > final
On Mon, 2018-02-26 at 14:53 +, Ruslan Nikolaev via gcc wrote:
> Thank you for more comments, my response is below.
>
>
>
> On Mon, 26 Feb 2018, Szabolcs Nagy wrote:>
> > rmw load is only valid if the implementation can
> > guarantee that atomic objects are never read-only.
> But per respons
On Fri, 2017-10-20 at 18:46 +0300, Alexander Monakov wrote:
> On Fri, 20 Oct 2017, Torvald Riegel wrote:
> > On Thu, 2017-10-19 at 15:31 +0300, Alexander Monakov wrote:
> > > On Thu, 19 Oct 2017, Andrew Haley wrote:
> > > > No, you did not. This looks
On Fri, 2017-10-20 at 12:47 +0200, Torvald Riegel wrote:
> On Thu, 2017-10-19 at 13:58 +0200, Mattias Rönnblom wrote:
> > Hi.
> >
> > I have this code:
> >
> > #include
> >
> > int ready;
> > int message;
> >
> > void send_x4711(i
On Thu, 2017-10-19 at 13:18 +0100, Andrew Haley wrote:
> On 19/10/17 13:10, Jonathan Wakely wrote:
> > There are no atomic operations on atomic objects here, so the fence
> > doesn't synchronize with anything.
>
> Really? This seems rather unhelpful, to say the least.
>
> An atomic release opera
On Thu, 2017-10-19 at 15:31 +0300, Alexander Monakov wrote:
> On Thu, 19 Oct 2017, Andrew Haley wrote:
> > On 19/10/17 12:58, Mattias Rönnblom wrote:
> > > Did I misunderstand the semantics of
> > > atomic_thread_fence+memory_order_release?
> >
> > No, you did not. This looks like a bug. Please
On Thu, 2017-10-19 at 13:58 +0200, Mattias Rönnblom wrote:
> Hi.
>
> I have this code:
>
> #include
>
> int ready;
> int message;
>
> void send_x4711(int m) {
> message = m*4711;
> atomic_thread_fence(memory_order_release);
> ready = 1;
> }
>
> When I compile it with GCC 7.2 -O
On Tue, 2017-09-19 at 15:36 +0200, Florian Weimer wrote:
> On 09/19/2017 03:32 PM, Torvald Riegel wrote:
> > On Tue, 2017-09-19 at 07:19 +0200, Florian Weimer wrote:
> >> On 09/18/2017 10:07 PM, Torvald Riegel wrote:
> >>> On Mon, 2017-09-18 at 14:19 +0200, Floria
On Tue, 2017-09-19 at 07:19 +0200, Florian Weimer wrote:
> On 09/18/2017 10:07 PM, Torvald Riegel wrote:
> > On Mon, 2017-09-18 at 14:19 +0200, Florian Weimer wrote:
> >> I would like to see the GCC project to document that if the address of a
> >> member is taken,
On Mon, 2017-09-18 at 14:19 +0200, Florian Weimer wrote:
> I would like to see the GCC project to document that if the address of a
> member is taken, this does not constitute an access to the object as a
> whole.
>
> That is, in the following code:
>
> #include
>
> struct S {
>_Atomic in
On Thu, 2017-08-03 at 17:32 +0200, Torvald Riegel wrote:
> On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote:
> > Torvald Riegel writes:
> > > On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote:
> > >> (1) Does the approach seem reasonable?
&g
On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote:
> Torvald Riegel writes:
> > On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote:
> >> (1) Does the approach seem reasonable?
> >>
> >> (2) Would it be acceptable in principle to add th
On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote:
> (1) Does the approach seem reasonable?
>
> (2) Would it be acceptable in principle to add this extension to the
> GCC C frontend (only enabled where necessary)?
>
> (3) Should we submit this to the standards committee?
I h
On Tue, 2017-01-24 at 13:06 -0800, Richard Henderson wrote:
> On 01/24/2017 01:08 AM, Torvald Riegel wrote:
> > Unless HW transactions are guaranteed to succeed for scenarios that are
> > sufficient for the atomics, HTM won't help because we'd have to consider
> > t
On Fri, 2017-01-20 at 09:55 -0800, Richard Henderson wrote:
> On 01/19/2017 10:23 AM, Torvald Riegel wrote:
> > I think I prefer Option 3b as the short-term solution. It does not
> > break programs (except the __atomic_always_lock_free assertion scenario,
> > but that's
If using -mcx16 (directly or indirectly) today, then cmpxchg16b is used
to implement atomic loads too. I consider this a bug because it can
result in a store being issued (e.g., when loading from a read-only
page, or when trying to do a volatile atomic load), and because it can
increase contention
On Thu, 2016-12-22 at 11:37 -0600, Segher Boessenkool wrote:
> On Thu, Dec 22, 2016 at 03:28:56PM +0100, Ulrich Weigand wrote:
> > However, there still seems to be a problem, but this time related to
> > alignment issues. We do have the 16-byte atomic instructions, but they
> > only work on 16-byt
On Wed, 2017-01-18 at 14:23 -0800, Richard Henderson wrote:
> On 01/17/2017 09:00 AM, Torvald Riegel wrote:
> > I think the ABI should set a baseline for each architecture, and the
> > baseline decides whether something is inlinable or not. Thus, the
> > x86_64 ABI would mak
On Thu, 2016-11-17 at 12:12 -0800, Bin Fan wrote:
> On 11/14/2016 4:34 PM, Bin Fan wrote:
> > Hi All,
> >
> > I have an updated version of libatomic ABI specification draft. Please
> > take a look to see if it matches GCC implementation. The purpose of
> > this document is to establish an officia
On Fri, 2016-12-02 at 12:13 +0100, Gabriel Paubert wrote:
> On Thu, Dec 01, 2016 at 11:13:37AM -0800, Bin Fan at Work wrote:
> > Hi Szabolcs,
> >
> > > On Nov 29, 2016, at 3:11 AM, Szabolcs Nagy wrote:
> > >
> > > On 17/11/16 20:12, Bin Fan wrote:
> > >>
> > >> Although this ABI specification s
On Fri, 2016-06-03 at 13:46 +0100, Kyrill Tkachov wrote:
> Hi Jakub, Torvald,
>
> On 03/06/16 13:32, Jakub Jelinek wrote:
> > On Fri, Jun 03, 2016 at 02:26:09PM +0200, Torvald Riegel wrote:
> >> And that would be fine, IMO. If you can't even load atomically, doing
&g
On Fri, 2016-06-03 at 14:32 +0200, Jakub Jelinek wrote:
> On Fri, Jun 03, 2016 at 02:26:09PM +0200, Torvald Riegel wrote:
> > And that would be fine, IMO. If you can't even load atomically, doing
> > something useful with this type will be hard except in special cases.
&
On Fri, 2016-06-03 at 12:03 +0200, Jakub Jelinek wrote:
> On Fri, Jun 03, 2016 at 10:34:15AM +0100, Kyrill Tkachov wrote:
> > expand_atomic_load in optabs.c tries to expand a wide atomic load using an
> > atomic_compare_and_swap
> > with the comment saying that sometimes a redundant harmless store
On Mon, 2016-05-09 at 12:25 -0700, Ian Lance Taylor wrote:
> On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote:
> >
> > The *context APIs are deprecated and I'm not sure they're worth
> > supporting with this. It would be a good excuse to get people to stop
> > using them.
>
> The gccgo library
On Thu, 2016-04-14 at 10:24 +0800, lh_mouse wrote:
> Yes I learnt those *ByAddress* functions a few months ago and was shocked
> that Microsoft had plagiarized futex from Linux.
> As you have pointed out already, those APIs are only available on Windows 8
> and later.
Yes. On Windows 8, given
On Wed, 2016-04-13 at 17:17 +0800, lh_mouse wrote:
> Hi all,
>
> The 'win32' thread model of gcc has been there since long long ago, being
> compatible with very old Windows versions, also having a number of drawbacks:
> 0) its implementation is very inefficient, and
> 1) its mutexes and cond
On Fri, 2016-02-26 at 20:10 +0100, Torvald Riegel wrote:
> On Fri, 2016-02-26 at 11:49 +0100, Richard Biener wrote:
> > On Thu, Feb 25, 2016 at 6:33 PM, Torvald Riegel wrote:
> > > On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote:
> > >> On Tue, Feb 23, 2
On Fri, 2016-02-26 at 11:49 +0100, Richard Biener wrote:
> On Thu, Feb 25, 2016 at 6:33 PM, Torvald Riegel wrote:
> > On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote:
> >> On Tue, Feb 23, 2016 at 8:38 PM, Torvald Riegel wrote:
> >> > I'd like to kno
On Thu, 2016-02-25 at 18:33 +0100, Torvald Riegel wrote:
> On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote:
> > On Tue, Feb 23, 2016 at 8:38 PM, Torvald Riegel wrote:
> > > I'd like to know, based on the GCC experience, how important we consider
> > >
On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote:
> On Tue, Feb 23, 2016 at 8:38 PM, Torvald Riegel wrote:
> > I'd like to know, based on the GCC experience, how important we consider
> > optimizations that may turn data dependencies of pointers into control
> > d
I'd like to know, based on the GCC experience, how important we consider
optimizations that may turn data dependencies of pointers into control
dependencies. I'm thinking about all optimizations or transformations
that guess that a pointer might have a specific value, and then create
(specialized)
On Wed, 2016-01-20 at 20:22 -0500, Rich Felker wrote:
> On Thu, Jan 21, 2016 at 08:08:18AM +0900, Oleg Endo wrote:
> > Do you have plans to add other atomic operations (like
> > arithmetic)?
>
> No, at least not in musl. From musl's perspective cas is the main one
> that's used anyway. But even in
On Fri, 2015-07-17 at 13:33 +0200, Sebastian Huber wrote:
> On 17/07/15 13:26, Jakub Jelinek wrote:
> > On Fri, Jul 17, 2015 at 01:17:32PM +0200, Sebastian Huber wrote:
> >> >On 17/07/15 08:40, Sebastian Huber wrote:
> >>> > >Hello,
> >>> > >
> >>> > >the libgomp configuration for RTEMS uses curren
On Thu, 2015-05-21 at 13:42 -0700, Linus Torvalds wrote:
> On Thu, May 21, 2015 at 1:02 PM, Paul E. McKenney
> wrote:
> >
> > The compiler can (and does) speculate non-atomic non-volatile writes
> > in some cases, but I do not believe that it is permitted to speculate
> > either volatile or atomic
On Tue, 2015-05-19 at 17:55 -0700, Paul E. McKenney wrote:
> http://www.rdrop.com/users/paulmck/RCU/consume.2015.05.18a.pdf
I have been discussing Section 7.9 with Paul during last week.
While I think that 7.9 helps narrow down the problem somewhat, I'm still
concerned that it effectively
This adds a POSIX-based implementation of shared_timed_mutex, using
pthread_rwlock_* operations directly instead of implementing with
mutexes and two condvars. This enables using an optimized
pthread_rwlock_t on POSIX.
Tested on x86_64-linux.
OK?
2015-01-16 Torvald Riegel
* include
On Fri, 2014-12-26 at 22:26 +, Andrew Haley wrote:
> On 26/12/14 20:32, Matt Godbolt wrote:
>
> > I'm investigating ways to have single-threaded writers write to memory
> > areas which are then (very infrequently) read from another thread for
> > monitoring purposes. Things like "number of uni
On Fri, 2014-12-26 at 23:19 +, Andrew Haley wrote:
> On 26/12/14 22:49, Matt Godbolt wrote:
> > At the moment I think the best I can do is to use an inline assembly
> > version of the increment which prevents GCC from doing any
> > optimisation upon it. That seems rather ugly though, and if any
On Tue, 2014-04-29 at 09:11 -0400, Leo Ferres wrote:
> Hello,
>
> Suppose the following C code.
>
> int t = __sync_fetch_and_add(&s->r, 1);
>
> s is a struct with member r, which is an volatile int.
>
> Is this an atomic operation, even if you include the indirection?
The atomic operation is o
On Wed, 2014-03-05 at 10:15 -0800, Paul E. McKenney wrote:
> On Wed, Mar 05, 2014 at 05:54:59PM +0100, Torvald Riegel wrote:
> > On Tue, 2014-03-04 at 13:35 -0800, Paul E. McKenney wrote:
> > > On Tue, Mar 04, 2014 at 11:00:32AM -0800, Paul E. McKenney wrote:
> > > >
On Wed, 2014-03-05 at 10:01 -0800, Paul E. McKenney wrote:
> On Wed, Mar 05, 2014 at 05:26:36PM +0100, Torvald Riegel wrote:
> > xagsmtp3.20140305162928.8...@uk1vsc.vnet.ibm.com
> > X-Xagent-Gateway: uk1vsc.vnet.ibm.com (XAGSMTP3 at UK1VSC)
> >
> > On Tue, 2014-0
On Tue, 2014-03-04 at 22:11 +, Peter Sewell wrote:
> On 3 March 2014 20:44, Torvald Riegel wrote:
> > On Sun, 2014-03-02 at 04:05 -0600, Peter Sewell wrote:
> >> On 1 March 2014 08:03, Paul E. McKenney wrote:
> >> > On Sat, Mar 01, 2014 at 04:06:34AM -0600,
On Tue, 2014-03-04 at 13:35 -0800, Paul E. McKenney wrote:
> On Tue, Mar 04, 2014 at 11:00:32AM -0800, Paul E. McKenney wrote:
> > On Mon, Mar 03, 2014 at 09:46:19PM +0100, Torvald Riegel wrote:
> > > xagsmtp2.20140303204700.3...@vmsdvma.vnet.ibm.com
> > > X-Xagent-Ga
On Tue, 2014-03-04 at 11:00 -0800, Paul E. McKenney wrote:
> On Mon, Mar 03, 2014 at 09:46:19PM +0100, Torvald Riegel wrote:
> > xagsmtp2.20140303204700.3...@vmsdvma.vnet.ibm.com
> > X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA)
> >
> > On Mon, 2014-0
On Mon, 2014-03-03 at 11:20 -0800, Paul E. McKenney wrote:
> On Mon, Mar 03, 2014 at 07:55:08PM +0100, Torvald Riegel wrote:
> > xagsmtp2.20140303190831.9...@uk1vsc.vnet.ibm.com
> > X-Xagent-Gateway: uk1vsc.vnet.ibm.com (XAGSMTP2 at UK1VSC)
> >
> > On Fri, 2014-0
On Sun, 2014-03-02 at 04:05 -0600, Peter Sewell wrote:
> On 1 March 2014 08:03, Paul E. McKenney wrote:
> > On Sat, Mar 01, 2014 at 04:06:34AM -0600, Peter Sewell wrote:
> >> Hi Paul,
> >>
> >> On 28 February 2014 18:50, Paul E. McKenney
> >> wrote:
> >> > On Thu, Feb 27, 2014 at 12:53:12PM -080
On Thu, 2014-02-27 at 17:02 -0800, Paul E. McKenney wrote:
> On Thu, Feb 27, 2014 at 09:50:21AM -0800, Paul E. McKenney wrote:
> > On Thu, Feb 27, 2014 at 04:37:33PM +0100, Torvald Riegel wrote:
> > > xagsmtp2.20140227154925.3...@vmsdvm9.vnet.ibm.com
> > >
> > &g
On Fri, 2014-02-28 at 16:50 -0800, Paul E. McKenney wrote:
> +oDo not use the results from the boolean "&&" and "||" when
> + dereferencing. For example, the following (rather improbable)
> + code is buggy:
> +
> + int a[2];
> + int index;
> + int fo
On Thu, 2014-02-27 at 09:50 -0800, Paul E. McKenney wrote:
> Your proposal looks quite promising at first glance. But rather than
> try and comment on it immediately, I am going to take a number of uses of
> RCU from the Linux kernel and apply your proposal to them, then respond
> with the results
On Thu, 2014-02-27 at 11:47 -0800, Linus Torvalds wrote:
> On Thu, Feb 27, 2014 at 11:06 AM, Paul E. McKenney
> wrote:
> >
> > 3. The comparison was against another RCU-protected pointer,
> > where that other pointer was properly fetched using one
> > of the RCU primitives. H
On Thu, 2014-02-27 at 09:01 -0800, Linus Torvalds wrote:
> On Thu, Feb 27, 2014 at 7:37 AM, Torvald Riegel wrote:
> > Regarding the latter, we make a fresh start at each mo_consume load (ie,
> > we assume we know nothing -- L could have returned any possible value);
> > I b
On Fri, 2014-02-28 at 12:37 +0100, Thomas Schwinge wrote:
> Does it make sense to add the option for the user to install a handler
> for this?
The problem with calling a handler is that it's often hard to define
which state the program is in during the handler. If libgomp had to
terminate because
On Mon, 2014-02-24 at 11:54 -0800, Linus Torvalds wrote:
> On Mon, Feb 24, 2014 at 10:53 AM, Paul E. McKenney
> wrote:
> >
> > Good points. How about the following replacements?
> >
> > 3. Adding or subtracting an integer to/from a chained pointer
> > results in another chained point
On Wed, 2014-02-26 at 18:43 +, Joseph S. Myers wrote:
> On Wed, 26 Feb 2014, Torvald Riegel wrote:
>
> > On Fri, 2014-02-21 at 22:10 +, Joseph S. Myers wrote:
> > > On Fri, 21 Feb 2014, Paul E. McKenney wrote:
> > >
>
On Mon, 2014-02-24 at 09:28 -0800, Paul E. McKenney wrote:
> On Mon, Feb 24, 2014 at 05:55:50PM +0100, Michael Matz wrote:
> > Hi,
> >
> > On Mon, 24 Feb 2014, Linus Torvalds wrote:
> >
> > > > To me that reads like
> > > >
> > > > int i;
> > > > int *q = &i;
> > > > int **p = &q;
> > > >
>
On Mon, 2014-02-24 at 09:38 -0800, Linus Torvalds wrote:
> On Mon, Feb 24, 2014 at 8:55 AM, Michael Matz wrote:
> >
> > So, let me try to poke holes into your definition or increase my
> > understanding :) . You said "chain of pointers"(dereferences I assume),
> > e.g. if p is result of consume l
On Fri, 2014-02-21 at 22:10 +, Joseph S. Myers wrote:
> On Fri, 21 Feb 2014, Paul E. McKenney wrote:
>
> > This needs to be as follows:
> >
> > [[carries_dependency]] int getzero(int i [[carries_dependency]])
> > {
> > return i - i;
> > }
> >
> > Otherwise dependencies won't get carried
On Fri, 2014-02-21 at 11:13 -0800, Paul E. McKenney wrote:
> On Fri, Feb 21, 2014 at 07:35:37PM +0100, Michael Matz wrote:
> > Hi,
> >
> > On Thu, 20 Feb 2014, Linus Torvalds wrote:
> >
> > > But I'm pretty sure that any compiler guy must *hate* that current odd
> > > dependency-generation part,
On Thu, 2014-02-20 at 11:09 -0800, Linus Torvalds wrote:
> On Thu, Feb 20, 2014 at 10:53 AM, Torvald Riegel wrote:
> > On Thu, 2014-02-20 at 10:32 -0800, Linus Torvalds wrote:
> >> On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney
> >> wrote:
> >> >
>
On Thu, 2014-02-20 at 10:18 -0800, Paul E. McKenney wrote:
> On Thu, Feb 20, 2014 at 06:26:08PM +0100, Torvald Riegel wrote:
> > xagsmtp2.20140220172700.0...@vmsdvm4.vnet.ibm.com
> > X-Xagent-Gateway: vmsdvm4.vnet.ibm.com (XAGSMTP2 at VMSDVM4)
> >
> > On Wed, 2014-0
On Thu, 2014-02-20 at 10:32 -0800, Linus Torvalds wrote:
> On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney
> wrote:
> >
> > You really need that "consume" to be "acquire".
>
> So I think we now all agree that that is what the standard is saying.
Huh?
The standard says that there are two sep
On Thu, 2014-02-20 at 10:11 -0800, Paul E. McKenney wrote:
> But yes, the compiler guys would be extremely happy to simply drop
> memory_order_consume from the standard, as it is the memory order
> that they most love to hate.
>
> Getting them to agree to any sort of peep-hole optimization semanti
On Thu, 2014-02-20 at 09:01 -0800, Linus Torvalds wrote:
> On Thu, Feb 20, 2014 at 12:30 AM, Paul E. McKenney
> wrote:
> >>
> >> So lets make this really simple: if you have a consume->cmp->read, is
> >> the ordering of the two reads guaranteed?
> >
> > Not as far as I know. Also, as far as I kno
On Thu, 2014-02-20 at 09:34 -0800, Linus Torvalds wrote:
> On Thu, Feb 20, 2014 at 9:14 AM, Torvald Riegel wrote:
> >>
> >> So the clarification is basically to the statement that the "if
> >> (consume(p)) a" version *would* have an ordering guarantee betwe
On Thu, 2014-02-20 at 00:30 -0800, Paul E. McKenney wrote:
> Well, all the compilers currently convert consume to acquire, so you have
> your wish there. Of course, that also means that they generate actual
> unneeded memory-barrier instructions, which seems extremely sub-optimal
> to me.
GCC doe
On Wed, 2014-02-19 at 20:43 -0800, Linus Torvalds wrote:
[Paul has already answered many of your questions, and my reply to your
previous email should also answer some.]
> If the consumer of an atomic load isn't a pointer chasing operation,
> then the consume should be defined to be the same as a
On Wed, 2014-02-19 at 20:01 -0800, Paul E. McKenney wrote:
> On Wed, Feb 19, 2014 at 04:53:49PM -0800, Linus Torvalds wrote:
> > On Tue, Feb 18, 2014 at 11:47 AM, Torvald Riegel wrote:
> > > On Tue, 2014-02-18 at 09:44 -0800, Linus Torvalds wrote:
> > >>
> > &
On Wed, 2014-02-19 at 16:53 -0800, Linus Torvalds wrote:
> On Tue, Feb 18, 2014 at 11:47 AM, Torvald Riegel wrote:
> > On Tue, 2014-02-18 at 09:44 -0800, Linus Torvalds wrote:
> >>
> >> Can you point to it? Because I can find a draft standard, and it sure
> >
On Wed, 2014-02-19 at 07:23 -0800, David Lang wrote:
> On Tue, 18 Feb 2014, Torvald Riegel wrote:
>
> > On Tue, 2014-02-18 at 22:40 +0100, Peter Zijlstra wrote:
> >> On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
> >>> Well, that's how atomi
On Wed, 2014-02-19 at 07:14 -0800, Paul E. McKenney wrote:
> On Wed, Feb 19, 2014 at 11:59:08AM +0100, Torvald Riegel wrote:
> > On Tue, 2014-02-18 at 14:58 -0800, Paul E. McKenney wrote:
> > > On Tue, Feb 18, 2014 at 10:40:15PM +0100, Torvald Riegel wrote:
> > >
On Tue, 2014-02-18 at 14:14 -0800, Linus Torvalds wrote:
> On Tue, Feb 18, 2014 at 1:21 PM, Torvald Riegel wrote:
> >>
> >> So imagine that you have some clever global optimizer that sees that
> >> the program never ever actually sets the dirty bit at all in any
&
On Tue, 2014-02-18 at 22:47 +0100, Peter Zijlstra wrote:
> On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
> > Yes, I do. But that seems to be "volatile" territory. It crosses the
> > boundaries of the abstract machine, and thus is input/output. Which
&g
On Tue, 2014-02-18 at 14:58 -0800, Paul E. McKenney wrote:
> On Tue, Feb 18, 2014 at 10:40:15PM +0100, Torvald Riegel wrote:
> > xagsmtp4.20140218214207.8...@vmsdvm9.vnet.ibm.com
> > X-Xagent-Gateway: vmsdvm9.vnet.ibm.com (XAGSMTP4 at VMSDVM9)
> >
> > On Tue, 2014-0
On Tue, 2014-02-18 at 22:52 +0100, Peter Zijlstra wrote:
> > > 4.Some drivers allow user-mode code to mmap() some of their
> > > state. Any changes undertaken by the user-mode code would
> > > be invisible to the compiler.
> >
> > A good point, but a compiler that doesn't try to (inco
On Tue, 2014-02-18 at 23:48 +, Peter Sewell wrote:
> On 18 February 2014 20:43, Torvald Riegel wrote:
> > On Tue, 2014-02-18 at 12:12 +, Peter Sewell wrote:
> >> Several of you have said that the standard and compiler should not
> >> permit speculative writes
On Tue, 2014-02-18 at 22:40 +0100, Peter Zijlstra wrote:
> On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
> > Well, that's how atomics that aren't volatile are defined in the
> > standard. I can see that you want something else too, but that doesn't
On Tue, 2014-02-18 at 09:16 -0800, Paul E. McKenney wrote:
> On Tue, Feb 18, 2014 at 08:49:13AM -0800, Linus Torvalds wrote:
> > On Tue, Feb 18, 2014 at 7:31 AM, Torvald Riegel wrote:
> > > On Mon, 2014-02-17 at 16:05 -0800, Linus Torvalds wrote:
> > >> And exactly
On Tue, 2014-02-18 at 08:49 -0800, Linus Torvalds wrote:
> On Tue, Feb 18, 2014 at 7:31 AM, Torvald Riegel wrote:
> > On Mon, 2014-02-17 at 16:05 -0800, Linus Torvalds wrote:
> >> And exactly because I know enough, I would *really* like atomics to be
> >> well-defined
On Tue, 2014-02-18 at 18:21 +, Peter Sewell wrote:
> On 18 February 2014 17:38, Linus Torvalds
> wrote:
> > On Tue, Feb 18, 2014 at 4:12 AM, Peter Sewell
> > wrote:
> >>
> >> For example, suppose we have, in one compilation unit:
> >>
> >> void f(int ra, int*rb) {
> >> if (ra==42)
On Tue, 2014-02-18 at 12:12 +, Peter Sewell wrote:
> Several of you have said that the standard and compiler should not
> permit speculative writes of atomics, or (effectively) that the
> compiler should preserve dependencies. In simple examples it's easy
> to see what that means, but in gener
On Tue, 2014-02-18 at 08:55 -0800, Paul E. McKenney wrote:
> On Tue, Feb 18, 2014 at 04:38:40PM +0100, Torvald Riegel wrote:
> > On Mon, 2014-02-17 at 16:18 -0800, Linus Torvalds wrote:
> > > On Mon, Feb 17, 2014 at 3:41 PM, Torvald Riegel
> > > wrote:
> >
On Tue, 2014-02-18 at 09:44 -0800, Linus Torvalds wrote:
> On Tue, Feb 18, 2014 at 8:17 AM, Torvald Riegel wrote:
> > The standard is clear on what's required. I strongly suggest reading
> > the formalization of the memory model by Batty et al.
>
> Can you point t
On Mon, 2014-02-17 at 16:09 -0800, Linus Torvalds wrote:
> On Mon, Feb 17, 2014 at 3:17 PM, Torvald Riegel wrote:
> > On Mon, 2014-02-17 at 14:32 -0800,
> >
> >> Stop claiming it "can return 1".. It *never* returns 1 unless you do
> >> the load and *v
On Mon, 2014-02-17 at 19:42 -0800, Linus Torvalds wrote:
> On Mon, Feb 17, 2014 at 7:24 PM, Linus Torvalds
> wrote:
> >
> > As far as I can tell, the intent is that you can't do value
> > speculation (except perhaps for the "relaxed", which quite frankly
> > sounds largely useless).
>
> Hmm. The
On Mon, 2014-02-17 at 19:00 -0800, Paul E. McKenney wrote:
> On Mon, Feb 17, 2014 at 12:18:21PM -0800, Linus Torvalds wrote:
> > On Mon, Feb 17, 2014 at 11:55 AM, Torvald Riegel wrote:
> > >
> > > Which example do you have in mind here? Haven't we resolved all th
On Mon, 2014-02-17 at 16:18 -0800, Linus Torvalds wrote:
> On Mon, Feb 17, 2014 at 3:41 PM, Torvald Riegel wrote:
> >
> > There's an underlying problem here that's independent from the actual
> > instance that you're worried about here: "no sense" is
On Mon, 2014-02-17 at 16:05 -0800, Linus Torvalds wrote:
> And exactly because I know enough, I would *really* like atomics to be
> well-defined, and have very clear - and *local* - rules about how they
> can be combined and optimized.
"Local"?
> None of this "if you can prove that the read has v
On Mon, 2014-02-17 at 14:47 -0800, Linus Torvalds wrote:
> On Mon, Feb 17, 2014 at 2:25 PM, Torvald Riegel wrote:
> > On Mon, 2014-02-17 at 14:02 -0800, Linus Torvalds wrote:
> >>
> >> The argument was that an lvalue doesn't actually "access"
On Mon, 2014-02-17 at 14:32 -0800, Linus Torvalds wrote:
> On Mon, Feb 17, 2014 at 2:09 PM, Torvald Riegel wrote:
> > On Sat, 2014-02-15 at 11:15 -0800, Linus Torvalds wrote:
> >> >
> >> > if (atomic_load(&x, mo_relaxed) == 1)
> >> > atomic_stor
1 - 100 of 183 matches
Mail list logo
