LWN: Comments on "Lockless algorithms for mere mortals" https://lwn.net/Articles/827180/ This is a special feed containing comments posted to the individual LWN article titled "Lockless algorithms for mere mortals". en-us Sat, 25 Oct 2025 08:38:50 +0000 Sat, 25 Oct 2025 08:38:50 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Lockless algorithms for mere mortals https://lwn.net/Articles/849351/ https://lwn.net/Articles/849351/ alison <div class="FormattedComment"> <font class="QuotedText">&gt; It&#x27;s not just Newtonian physics, it&#x27;s all macroscopic physics. In relativistic space-time, about the only thing preserved is causation [0].</font><br> <p> Sadly, Bell&#x27;s Inequality shows that the combination of quantum mechanics and relativity spells trouble for causality, too. See, for example, <br> <p> <a href="https://phys.org/news/2017-07-probability-quantum-world-local-realism.html">https://phys.org/news/2017-07-probability-quantum-world-l...</a><br> <p> &quot;By performing an essentially loophole-free Bell test, they have shown that two atoms separated by a distance of a quarter of a mile share correlations that should be impossible under the hypothesis of local realism, and are most likely explained by quantum entanglement.&quot;<br> <p> &quot;Local realism&quot; here means that even Reality has only &quot;eventual consistency.&quot; Senior, respected, widely published physicists believe this and have done so for decades. Quantum entanglement is harder to reason about then memory ordering and consistency. Einstein&#x27;s famous comment that &quot;God does not play dice&quot; was in response to discussions of this topic. <br> </div> Mon, 15 Mar 2021 16:01:35 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/834149/ https://lwn.net/Articles/834149/ immibis <div class="FormattedComment"> I&#x27;ll try to give an intuitive explanation for why erasing data must cost energy. Premise: we know that the universe is reversible. If state A goes to state B, then state reverse(B) must go to state reverse(A).<br> <p> Therefore you can&#x27;t have states A and B which both go to C, because a universe in state reverse(C) wouldn&#x27;t know whether to go to reverse(A) or reverse(B). Information cannot be deleted.<br> <p> So how do computers delete information, then? Well, the universe is full of states we don&#x27;t care about, so we just cheat and move the information to one of those. For example, writing 1 releases energy from a different point in the chip than writing 0, which causes a different vibration in the silicon lattice, which transfers to the plastic packaging, which causes an air molecule to bounce off the chip differently.<br> <p> That means if there are 1 zillion different ways the air molecules would&#x27;ve bounced (if the chip was turned off), now there are 2 zillion, because all the bounces after 0 is written are different from all the bounces after 1 is written. Obviously air can bounce a lot of ways - but the problem is that all of the 1-zillion input states map to 1-zillion output states already. There&#x27;s no way to get more output states than input states without giving the molecule more energy - which allows it to be in states it couldn&#x27;t be in with its previous amount of energy. Therefore the chip must have transferred a bit of energy to the air molecule. There is no other way it could work.<br> <p> All of this applies *on average*, by the way.<br> <p> Or here&#x27;s a different explanation: If you consider a computer that&#x27;s known to be in 1 of 1000 states, and the air in the room that&#x27;s in 1 of 1 zillion states, there are 1000 zillion states in total (the cartesian product). If the computer is in 1 of 500 states in the next timestep, there still must be 1000 zillion states for the computer+air system, because the universe is reversible. Therefore the air must be in 1 of 2 zillion states. This doesn&#x27;t apply to reversible computers, because reversible computers *don&#x27;t* decrease their number of states in any time step.<br> </div> Tue, 13 Oct 2020 15:28:03 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/830884/ https://lwn.net/Articles/830884/ Cyberax <div class="FormattedComment"> <font class="QuotedText">&gt; if you attempt to simulate the structure and evolution of the large-scale universe using MOND or similar theories, the results look very very different from what we observe</font><br> This is actually questionable.<br> <p> Moreover, it has not been conclusively proven that galactic rotation curves can&#x27;t be explained by general relativity alone. Exact solutions of Einstein field equations are too simplistic for that and computer simulation is way too complicated for something like a galaxy. There are people working on this, but this is very un-glamorous area of research.<br> </div> Mon, 07 Sep 2020 20:07:22 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/830883/ https://lwn.net/Articles/830883/ nix <div class="FormattedComment"> <font class="QuotedText">&gt; might not the gravitational law ALSO change with mass-energy density, so that gravity is stronger in regions of low mass density like interstellar and intergalactic space?</font><br> <p> This is the basis of Mordehai Milgrom&#x27;s MOND (and a number of other similar things, some of which, unlike MOND, are modifications of relativity rather than Newton). They&#x27;re not widely accepted because while they get galaxies&#x27; rotational velocities right (it would be surprising if they didn&#x27;t), unfortunately, if you attempt to simulate the structure and evolution of the large-scale universe using MOND or similar theories, the results look very very different from what we observe. The people involved in MOND are major figures (not least Jakob Bekenstein, who nobody could claim doesn&#x27;t know his stuff where gravity is concerned), but MOND remains... problematic.<br> <p> (But it has nothing to do with Boyle&#x27;s law or with slowing of anything: MOND isn&#x27;t even relativistic, let alone quantized, and doesn&#x27;t mention gravitons at all. Its adjustments to Newton are ad-hoc to make the rotation curves of galaxies come out right.)<br> <p> <font class="QuotedText">&gt; Or, given that somebody said that gravitational waves travel at light speed, but light speed is not constant (c is a theoretical maximum), maybe the waves travel faster in low mass density?</font><br> <p> Massless particles (including photons) travel at c, always: don&#x27;t think of it as the speed of light, think of it as the speed of propagation of cause and effect, and massless particles max this out. In a medium, the apparent speed of light waves in particular (but no other massless particles) is reduced by coupling to the electromagnetic fields of charged particles in the medium (largely electrons): but this is a group effect on the wave as a whole, and the photons that make up the light are still moving at c!<br> <p> I suppose the same class of effect in theory could apply to changes in gravity, since gravitational waves should I believe couple to all masses they pass in the same way and slow in regions with higher mass density, but gravity is such a weak force that the effect would be incredibly tiny: it would almost certainly be as unobservable as the graviton itself even if you were hanging out next to a black hole. (So far, nobody has thought up a way to produce a graviton detector which isn&#x27;t so massive it collapses into a black hole. Gravity is *ridiculously* weak.)<br> <p> </div> Mon, 07 Sep 2020 19:19:40 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/830863/ https://lwn.net/Articles/830863/ Wol <div class="FormattedComment"> <font class="QuotedText">&gt; Using a massless ultra-low-energy particle to explain away the majority of the mass-energy density in the universe seems to me to be putting the cart so far before the horse that it&#x27;s in a different solar system.</font><br> <p> Except that&#x27;s not what I&#x27;m doing. Sorry if I&#x27;ve mangled my physics, but ?Boyle&#x27;s Ideal Gas Law only applies to a hot gas where the atoms/molecules bounce off each other. As the gas cools, the Gas Law changes.<br> <p> I&#x27;m saying that, just like with velocities where at slow speeds v1+v2 gives us the obvious answer but c+c gives us the extremely unintuitive answer of c, might not the gravitational law ALSO change with mass-energy density, so that gravity is stronger in regions of low mass density like interstellar and intergalactic space? After all, isn&#x27;t that one possible explanation for what we observe?<br> <p> Or, given that somebody said that gravitational waves travel at light speed, but light speed is not constant (c is a theoretical maximum), maybe the waves travel faster in low mass density?<br> <p> Cheers,<br> Wol<br> </div> Mon, 07 Sep 2020 16:46:53 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/830816/ https://lwn.net/Articles/830816/ nix <div class="FormattedComment"> Quite. Another way of putting it is that if gravitons exist, gravity is transmitted by *virtual* gravitons. Virtual particles are not real, thus cannot form a Bose-Einstein condensate. (And if real gravitons exist, which is debatable, they are going to be massless, only appear when masses *move* (just like photons in the electromagnetic field only appear when charged particles move), and incredibly low-energy: the best upper bound on the graviton&#x27;s Compton wavelength is over a light year! Using a massless ultra-low-energy particle to explain away the majority of the mass-energy density in the universe seems to me to be putting the cart so far before the horse that it&#x27;s in a different solar system. And while a BEC of gravitons is theoretically possible -- a BEC of photons has been produced, after all -- it seems massively unlikely to ever happen in the real universe.)<br> <p> Also, since both move at lightspeed, it makes about as much sense to say that gravitons can &quot;get colder&quot; as it does to say that light can &quot;get colder&quot;.<br> </div> Mon, 07 Sep 2020 12:38:49 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/830815/ https://lwn.net/Articles/830815/ nix <blockquote> That's how black holes evaporate as the Universe gets colder ... </blockquote> For the record, this is completely wrong. Black hole evaporation is a consequence of the differing appearance of the weave of spacetime to observers very close to, versus far from, the event horizon: a local version of the Unruh effect, as it were (or, rather, the Unruh effect is the same thing as Hawking evaporation applied to accelerating observers rather than observers in a gravitational field). It depends only on the mass of the hole and its event horizon radius. It happens even when the universe is hot: it happens even when the hole is still in the middle of its exploding progenitor star. It's just that until the universe is very old and cold (or the hole is exceptionally small, thus with a high Hawking temperature), the hole will gain more mass through absorbing intercepted microwave background radiation than it loses through Hawking radiation. But it's still losing mass through this effect all the time, nonetheless. <p> The process has nothing to do with the sign of gravitational potential energy at all. <p> (Yes, the Unruh effect is named after the same Bill Unruh who used to hang out on uk.comp.os.linux.) Mon, 07 Sep 2020 12:27:37 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/830786/ https://lwn.net/Articles/830786/ nix <div class="FormattedComment"> <font class="QuotedText">&gt; [2] Actually, it could well be the Maxwell daemon thing again. Sitting there, actively monitoring the room so you know when all the gas molecules are on one side of the room takes an external energy source.</font><br> <p> This was figured out a decade or so ago. You don&#x27;t need the cost of monitoring: even if that&#x27;s zero, the mere fact that the demon has to make a decision about whether to allow a given molecule through or not is enough to ensure that the entropy of the system (demon + box) always increases, given that the demon&#x27;s memory capacity is finite such that it eventually has to erase the states of some of its memory (increasing its entropy) in order to make more decisions about whether to let molecules through.<br> </div> Sun, 06 Sep 2020 17:43:28 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/828698/ https://lwn.net/Articles/828698/ briangordon <div class="FormattedComment"> It depends on what you&#x27;re doing with it. If you&#x27;re implementing a JVM I&#x27;m sure the technical details of the spec aren&#x27;t easy to grapple with, but the practical implications are reasonably intuitive for developers. That&#x27;s for isolated snippets of code though. In a complex system with lots of moving parts, it can still become ferociously difficult to maintain your invariants, so you usually want to work with abstractions that wrap the low-level primitives to make things as dead simple as possible. For example, the actor model has your code running in single-threaded actors that can only communicate by sending messages to each other - there&#x27;s concurrent code under the hood, but you don&#x27;t have to think about it.<br> </div> Wed, 12 Aug 2020 18:49:16 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827816/ https://lwn.net/Articles/827816/ farnz <p>I would say that machine-checkability is necessary but not sufficient. If the rules are so complex to encode that a computer can't verify that you're getting them right, then they are also too complex for a human to get right, too, and they are certainly too complex for a human code reviewer to reliably check. <p>That said, this is a minimum requirement, as you can have rules that a computer can reliably verify, but that humans get wrong - see DEC Alpha ordering for the classic example. Mon, 03 Aug 2020 10:12:40 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827811/ https://lwn.net/Articles/827811/ PaulMcKenney <div class="FormattedComment"> No it is not at all easy! Today&#x27;s systems are quite complex, and their are variations from one system to other (ostensibly identical) systems. And variations in a single system over time.<br> <p> There is a lot of existing code to do such measurement, however, but on the other hand creating your own can be quite instructive.<br> </div> Sun, 02 Aug 2020 17:27:37 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827810/ https://lwn.net/Articles/827810/ itsmycpu <div class="FormattedComment"> Currently working on a way to consistently precision-test execution times of short code fragments, as a side project...not as easy as it may sound. ;-)<br> <p> </div> Sun, 02 Aug 2020 17:05:26 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827809/ https://lwn.net/Articles/827809/ PaulMcKenney <div class="FormattedComment"> Well, if the use of memory_order_relaxed was obvious and trivial, Hans and I probably would not have written P2055R0. :-)<br> <p> It turns out that in C, all the atomic operations are already volatile, including atomic_load_explicit(), which is then pretty close to READ_ONCE().<br> <p> In contrast, in C++, atomic_load_explicit() can take either a volatile or a non-volatile pointer, which means that use of C++ atomic_load_explicit() on non-volatile pointers (the common case) will be subject to the transformation called out in N4444. This working paper is for C++ rather than for C, in case you were wondering why it leaves out the C-language case.<br> <p> And yes, JF and I are already calling for something like READ_ONCE() and WRITE_ONCE() in C++: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1382r1.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p...</a><br> </div> Sun, 02 Aug 2020 16:56:19 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827808/ https://lwn.net/Articles/827808/ PaulMcKenney <div class="FormattedComment"> Try it and measure the results!<br> <p> Of course, the results will likely vary not only across CPU families, but also within CPU families.<br> </div> Sun, 02 Aug 2020 16:45:21 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827806/ https://lwn.net/Articles/827806/ PaulMcKenney <div class="FormattedComment"> Hans and I were expecting people to refer to the cited sections of the working paper &quot;N2153: A simple and efficient memory model for weakly-ordered architectures&quot;, which covers this in detail, including step 3. But yes, that expectation might not apply to people unfamiliar with the committee. Plus N2153 was written before the C11 atomic API had been finalized, so some mapping is required to understand it.<br> <p> I have therefore expanded this section to make step 3 explicit. Thank you for pointing this out.<br> <p> There will be a P2055R1 at some point, but in the meantime you can access the LaTeX at <a href="https://github.com/paulmckrcu/WG21-relaxedguide.git">https://github.com/paulmckrcu/WG21-relaxedguide.git</a>.<br> </div> Sun, 02 Aug 2020 16:43:30 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827805/ https://lwn.net/Articles/827805/ PaulMcKenney <div class="FormattedComment"> My fond hope is that things like the Linux-kernel memory model can shorten that time in at least some cases. ;-)<br> </div> Sun, 02 Aug 2020 15:39:28 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827804/ https://lwn.net/Articles/827804/ PaulMcKenney <div class="FormattedComment"> No two ways about it, analogies with relativistic and quantum physics are way more cool than analogies against Newtonian physics. ;-)<br> </div> Sun, 02 Aug 2020 15:35:27 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827792/ https://lwn.net/Articles/827792/ jezuch <div class="FormattedComment"> It was probably very naive at the beginning, like a lot of Java. But I think the interesting thing is that, at least as I understand it, it&#x27;s specified in very different terms than the C model, which uses esoteric jargon, while the Java model tried to make it at least understandable for mere mortals. Not sure how well it succeeds - usually you don&#x27;t have to go into this level of detail unless you want to do something unusual, but at that point you&#x27;re clearly very clever, so... ;)<br> </div> Sun, 02 Aug 2020 07:02:32 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827775/ https://lwn.net/Articles/827775/ anton <blockquote> Machine-checkability does seem important. </blockquote> Or one might consider such a requirement (as well as the article) to be an indication that the concepts are too difficult to use. In other cases (e.g., wrt. page colouring), Linus Torvalds has written that he targets hardware that performs well without such complications, and that other hardware deserves what it gets. I think that is a sensible approach for memory ordering as well. Have a model that's easy to understand and performs ok on nice hardware (not sure if nice hardware already exists, but weak consistency certainly does not look nice to me); then hardware designers have an incentive to make their hardware nicer. <p>It seems to me that all this difficult-to-program memory ordering is there because multi-processors originally come from the supercomputing area, where hardware is still more expensive than software, and hardware designers can get away with making hardware that's hard to program correctly <em>and</em> efficiently. Sat, 01 Aug 2020 17:23:44 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827774/ https://lwn.net/Articles/827774/ anton All the data centers are at rest wrt each other, and wrt to the events they observe (Earth rotation may be an issue, but not at the ms resolution they work with). Differences in the gravity field are miniscule, but even if they were significant, they would only change the time scale, not the order of events; and scale can be corrected by scaling the measured time to correct for this effect. Sat, 01 Aug 2020 16:35:51 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827769/ https://lwn.net/Articles/827769/ itsmycpu <div class="FormattedComment"> To complete my thoughts about reference counting above:<br> <p> If the reference counter is incremented relaxed, (for common use cases) it implies that read/write access is synchronized separately. So I&#x27;d expect that decrementing can be relaxed as well if the thread that encounters a zero reference count still has read/write access (otherwise it should be enough to use a simple load-acquire on the synchronization variable).<br> <p> However the (separate) synchronization of read/write access, which can&#x27;t be relaxed, probably makes the gain look small in comparison, even on those platforms where it is larger. Which makes me wonder how large it is.<br> <p> </div> Sat, 01 Aug 2020 14:32:06 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827766/ https://lwn.net/Articles/827766/ itsmycpu <div class="FormattedComment"> Something I noticed in your article <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2055r0.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p...</a><br> In 2.3, it describes an atomic_thread_fence with acquire:<br> <p> <font class="QuotedText">&gt; The atomic_thread_fence() function can be used to order multiple sets of accesses, for example, by replacing a series of acquire loads with relaxed loads followed by an atomic_thread_fence(memory_order_acquire)</font><br> <p> In its shortness, this sentence suggests the sequence:<br> 1: A series of relaxed loads<br> 2: An acquire fence<br> <p> However reading <a href="https://en.cppreference.com/w/cpp/atomic/atomic_thread_fence">https://en.cppreference.com/w/cpp/atomic/atomic_thread_fence</a> suggests:<br> <p> 1: Reading a single synchronization variable (probably atomic relaxed, as in the example)<br> 2: An acquire fence<br> 3: A series of relaxed or non-atomic loads.<br> <p> If you don&#x27;t mind me pointing it out. Probably more like a typo.<br> </div> Sat, 01 Aug 2020 12:47:34 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827763/ https://lwn.net/Articles/827763/ pbonzini <div class="FormattedComment"> Paul, you don&#x27;t know how much it means to me that you confirm that my understanding makes sense! It only took 10 years. :-)<br> <p> Thank you very much!<br> </div> Sat, 01 Aug 2020 09:25:54 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827753/ https://lwn.net/Articles/827753/ itsmycpu <div class="FormattedComment"> Partial answer: In my most critical use case, I am using the reference counter also as a synchronization point, so I need acquire/release there. However in many cases making the reference count atomic will perhaps simply be a way to avoid the need to get exclusive write access.<br> <p> For example if thread A already increases the count before passing the pointer, in advance of decreasing its own reference, of course relaxed is sufficient. If thread B is the one to increase the count, I&#x27;d think there needs to be a direct or indirect synchronization point between B&#x27;s increment and A&#x27;s decrement. Otherwise each increment is atomic, but one can&#x27;t be sure which one happens first. However that synchronization point doesn&#x27;t have to be the counter itself. If it isn&#x27;t, then the question arises if decrementing can&#x27;t be relaxed as well. :) Especially if the count reaching zero can be taken as an indication that all read/write access has already been given up.<br> <p> So yes, I think that&#x27;s a valid example for relaxed. Had to think about it, though. :-)<br> <p> Here <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4444.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n...</a><br> you wrote that a compiler is allowed to replace <br> <p> while (tmp = atomic_load_explicit(a, memory_order_relaxed))<br> do_something_with(tmp);<br> <p> with<br> <p> while (tmp = atomic_load_explicit(a, memory_order_relaxed))<br> do_something_with(tmp);<br> do_something_with(tmp);<br> do_something_with(tmp);<br> do_something_with(tmp);<br> }<br> <p> If that is still the case according to current C/C++ definitions, why don&#x27;t you argue that the definition of memory_order_relaxed be refined to READ_ONCE and WRITE_ONCE? Or are you already?<br> </div> Sat, 01 Aug 2020 04:24:26 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827751/ https://lwn.net/Articles/827751/ ras <div class="FormattedComment"> <font class="QuotedText">&gt; In other words, you can just as easily argue that the present macro state is more likely to have evolved from past macro states which had more microstates.</font><br> <p> Actually no, you can&#x27;t. In the definition of entropy the number of microstates is fixed and you are measuring how many of those microstate arrangements look like a given macro state.<br> <p> That aside, no one is disputing there is a thermodynamic arrow of time. The argument being made is that all transitions between microstates are reversible, lossless in terms of information and equally likely in both directions. It&#x27;s possible for that to be true for micro states and yet there be preferred direction for the evolution of macro states. It&#x27;s not only possible, it&#x27;s what happens.<br> <p> It&#x27;s not only what happens, there is no mystery as to why it happens. For example, take a go board covered with black and white stones and assume we are near blind. If all black stones are on one side of the board and white on the other we can see that, so black/white is a macro state, but the rest of the possible microstate arrangements just look like grey to us, so grey is another macro state. Back/white corresponds to a few micro states where the black and white stores are poorly mixed. I think there are 361! / 181! possible board arrangements or about 10^431. Most of those states will look just grey - a random mixture of black and white. If the pieces are moving randomly, all of the microstates will be equally likely. This means the odds of seeing black/white instead of grey look to be about 1 in 10^245 if you assume 10% can be out of place. [0] If your go board starts in the black / white macro state, then is allowed to evolve through random 100% completely reversible symmetric swaps you will see it change to grey, and stay that way.<br> <p> That is the thermodynamic arrow of time. Yet it arose from a completely reversible process. Microstates and macro states are both reasonable ways of looking at the system. When we say time is reversible, we are talking about the former.<br> <p> [0] Caveat: I am deriving the formulas for these probabilities in my head, as I write this. They are almost certainly wrong.<br> <p> </div> Sat, 01 Aug 2020 04:11:22 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827749/ https://lwn.net/Articles/827749/ HenrikH <div class="FormattedComment"> Two full mb:s for inserting a single item in a linked list will probably be slower than just using a mutex for the whole operation, as stated above going lock-less is only of interest if you are after maximum possible performance and calling mb() at each step is not that.<br> </div> Sat, 01 Aug 2020 02:26:47 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827747/ https://lwn.net/Articles/827747/ ras <div class="FormattedComment"> Defending myself, my point wasn&#x27;t that you couldn&#x27;t explain what happens in terms of Newtonian physics. It is that personally I find it a pretty unsatisfying explanation. In Newtonian physics time and information are a given, causality is assumption - usually just an unstated assumption. If you are going to rely on unstated beliefs to derive something you may as well say God did it. In fact God is better in some ways - it at least makes the limits of your understanding plain.<br> <p> But, Newtonian physics is an emergent property of other sets of rules. In those rules time, information, and causality are fundamental building blocks. Information in particular goes pretty deep - for example as others have stated here the definition of thermodynamic entropy is actually not about all possible arrangements of particles because there is no way to tell if you have swapped two identical particles, so such rearrangements can&#x27;t be counted. How on earth does the Universe even know I can&#x27;t distinguish between them - it&#x27;s not as if it&#x27;s looking through my eyes. But it does know, because if I don&#x27;t discount the identical looking states when I calculate the energy I can extract from a thermodynamic inequality, I get the wrong answer. It goes even deeper in quantum mechanics. The different outcomes when you don&#x27;t and don&#x27;t know something become positively bizarre - plainly obvious interference patterns disappear just because I know something. [0]<br> <p> It was partly observations like these that are utterly inexplicable by Newtonian Physics that led to the development of quantum mechanics, and at the other end of the scale relativity. If you are going to start marking analogies between computers programmers struggles with what can and can&#x27;t be known and order things must happen (aka causality) and what physics has to say on the matter, you are far better starting with physics theories that feature those things front and centre, rather one one that ignores them completely.<br> <p> [0] To this day I&#x27;ve yet to find a answer as to why these bizarre quantum mechanic effects happen, so it&#x27;s this new physics is not _that_ satisfying. Instead &quot;all&quot; the physicists have done is built mathematical models of our universe that assume it happens, and those models are insanely accurate. So there is not doubt you must take the relationship between time and information, and causality into account. But the mechanism driving that relationship appears to be a total mystery. At least that my understanding, but I am just an fascinated bystander.<br> </div> Sat, 01 Aug 2020 02:09:19 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827742/ https://lwn.net/Articles/827742/ PaulMcKenney <div class="FormattedComment"> There are many use cases for which memory_order_relaxed is reliable and useful, but there are dragons as well. Part of the problem is that C and C++ do not respect dependencies (with a very few exceptions), so the dragons are much more difficult than they are for things like READ_ONCE() and WRITE_ONCE() in the Linux kernel.<br> <p> On the reference count increment, the trick is that although the increment can be relaxed, the act of passing it somewhere else must be properly ordered. This proper ordering is often supplied by something else, though, such as thread-creation primitives. Whether this is worthwhile can depend on the CPU.<br> </div> Fri, 31 Jul 2020 22:47:00 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827740/ https://lwn.net/Articles/827740/ itsmycpu <div class="FormattedComment"> The PDF is an interesting read (though it will take me a few days to go through it), thank you for the reference. Also Dekker synchronization so far escaped my attention, at least by name, I will be looking into it.<br> <p> My first impression regarding the described use cases of memory_order_relaxed is that it is worse than I thought. Not because I would doubt that there are algorithms that make good use of it (like seqLock), but because it seems really difficult to navigate the potential problems in most cases.<br> <p> For example the use in reference counting increments. Even if decrements are non-relaxed, it isn&#x27;t immediately obvious to me that increments can be relaxed. Although I am well aware that in the handover of a reference from thread A to thread B there needs to be a moment where an original reference is still in place, and that the atomic value itself is sequential for RMW operations like increment and decrement (which are already expensive enough), I would not be sure that thread B necessarily needs to execute the necessary barriers after incrementing the reference relaxed, and before starting to load values from the referenced object. This would seem to mean that the compiler (or the hardware) is free to move the effective load time to before the reference increment becomes effective. So the logic that prevents this is probably very tricky (at least from my point of view, unless I&#x27;m simply missing some principle that provides for verification to become much easier). My guess would be that the necessary barriers might be involved in assuring thread A that it can release its reference. But I&#x27;m not aware of a theoretical construct that would guarantee this expectation to always apply, in general, for unknown use cases.<br> <p> </div> Fri, 31 Jul 2020 22:09:42 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827741/ https://lwn.net/Articles/827741/ PaulMcKenney <div class="FormattedComment"> Music to my ears! And please don&#x27;t keep your views secret!!! It is always better when I am not the only one defending non-memory_order_seq_cst atomics. :-)<br> </div> Fri, 31 Jul 2020 21:27:48 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827738/ https://lwn.net/Articles/827738/ itsmycpu <div class="FormattedComment"> On x86, memory_order_seq_cst is not of practical interest because of the performance impact of the mfence instruction required in the implementation of the store operation.<br> <p> Maybe it&#x27;s a thing for college beginner class. ;)<br> <p> </div> Fri, 31 Jul 2020 21:11:20 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827733/ https://lwn.net/Articles/827733/ NYKevin <div class="FormattedComment"> <font class="QuotedText">&gt; Entropy increases because systems tend towards the macrostates which have the most microstates (again, purely because of statistics).</font><br> <p> The problem with this argument is that it is time-symmetric. In other words, you can just as easily argue that the present macrostate is more likely to have evolved from past macrostates which had more microstates. Observation tells us that the time-reversed argument is empirically wrong (because we observe entropy increasing as a function of time), which is a bit of a problem because it appears to be symmetric with the (empirically correct) non-reversed argument. The only (obvious) way to break this symmetry is to assert a boundary condition of low entropy at or near the beginning of the universe. This boundary condition, IMHO, is the real mystery: Why did the early universe have such low entropy? I don&#x27;t think we have a working answer to that question (yet).<br> </div> Fri, 31 Jul 2020 21:06:43 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827716/ https://lwn.net/Articles/827716/ PaulMcKenney <div class="FormattedComment"> Please feel free to send a patch implementing your reordering suggestions.<br> </div> Fri, 31 Jul 2020 18:02:50 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827713/ https://lwn.net/Articles/827713/ PaulMcKenney We recently had to defend <tt>memory_order_relaxed</tt> in the committee. Here is Hans Boehm's and my <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2055r0.pdf">A Relaxed Guide to <tt>memory_order_relaxed</tt> [PDF]</a> which was the basis of that defense. <p>The &ldquo;Dekker synchronization&rdquo; refers to the core of this locking algorithm, which as Paolo said is set up so that if two threads each doing a store to one variable followed by a load from the other, at least one of the threads sees the other's store. This is used heavily in the Linux kernel, for example, to correctly resolve wait/wakeup races. Fri, 31 Jul 2020 18:01:15 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827706/ https://lwn.net/Articles/827706/ PaulMcKenney Having per-subsystem documentation of the memory-ordering use cases of particular importance to that subsystem makes a lot of sense to me! Many of the five you call out are heavily used, but even given common documentation of a given use case, many subsystems might still want to cover special cases or how that use case interacts with the rest of the subsystem. <p>Naming is fun. Yet another common name for <a href="https://en.wikipedia.org/wiki/Dekker%27s_algorithm">Dekker synchronization</a> is store buffering. We probably need to list the common names for each use case in the LKMM documentation. <p>Good point on pthread_create() and pthread_join(). The same applies to things like mod_timer() and the resulting handler function. <p>Your point about C11 <tt>memory_order_seq_cst</tt> does me good, given how difficult it for me and a few others to get the committee to accept that the standard should include anything in addition than sequential consistency. ;-) Fri, 31 Jul 2020 17:55:12 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827703/ https://lwn.net/Articles/827703/ PaulMcKenney <div class="FormattedComment"> The complexity of memory ordering can be fully explained with normal Newtonian physics. For example, you can make good analogies between memory misordering and misordering of messages carried by sound waves.<br> <p> Simple propagation delay is more than enough to make all these apparent reorderings happen.<br> <p> But it is of course often more fun to think in terms of more trendy views of physics. ;-)<br> </div> Fri, 31 Jul 2020 17:14:17 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827702/ https://lwn.net/Articles/827702/ PaulMcKenney <div class="FormattedComment"> One of the motivations for LKMM was the increasing difficulty of dealing with memory-barriers.txt. In fact, LKMM is intended to be an automated replacement for large portions of memory-barriers.txt.<br> </div> Fri, 31 Jul 2020 16:56:48 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827677/ https://lwn.net/Articles/827677/ PaulMcKenney <div class="FormattedComment"> Thank you all for the bug report, and work has started on improving the documentation.<br> <p> I would never have believed this two years ago, but it just might be possible to get to a point where someone reading only the tools/memory-model documentation might have a fighting chance of being able to make good use of LKMM. Here is hoping, anyway...<br> </div> Fri, 31 Jul 2020 15:30:14 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827648/ https://lwn.net/Articles/827648/ joib <div class="FormattedComment"> I&#x27;m saying we don&#x27;t know. The standard model in particle physics encompasses every known interaction, except gravity. We don&#x27;t have a functioning theory of quantum gravity. That doesn&#x27;t mean that gravity isn&#x27;t quantised, but it could alternatively mean that gravity is fundamentally different from the other interactions (say, describing instead the curvature of space-time like in GR). We just don&#x27;t know yet.<br> <p> Gravity waves neither prove nor disprove that gravity is quantised, just like a plethora of electromagnetic wave phenomena that neither prove nor disprove that the electromagnetic field is quantised.<br> <p> And to be pedantic, a photon is a quantised excitation in the electromagnetic field (not the field itself). An electron is a quantised excitation in the electron-positron field. Sure, it would be nice and symmetrical if there analogously would be a &quot;graviton&quot;. Unfortunately nature doesn&#x27;t much care for our notions of beauty and symmetry, and so far has resisted our efforts to crack this particular nut.<br> </div> Fri, 31 Jul 2020 11:01:47 +0000 Lockless algorithms for mere mortals https://lwn.net/Articles/827645/ https://lwn.net/Articles/827645/ Wol <div class="FormattedComment"> Are you saying that gravity is the only known wave without an associated particle?<br> <p> A photon is an electro-magnetic wave. An electron is a wave (not sure what in :-). Symmetry says surely a gravitational wave has a graviton?<br> <p> Cheers,<br> Wol<br> </div> Fri, 31 Jul 2020 08:47:10 +0000