|
|
Log in / Subscribe / Register

An introduction to lockless algorithms

An introduction to lockless algorithms

Posted Feb 20, 2021 2:55 UTC (Sat) by excors (subscriber, #95769)
In reply to: An introduction to lockless algorithms by gus3
Parent article: An introduction to lockless algorithms

It's also important what rules *aren't* stated. There's no requirement e.g. that for any two events P and Q, you can always determine either that P happens before Q or that Q happens before P. It's perfectly acceptable for there to be no ordering between them (except where the axioms say there must be an ordering).

That's contrary to the everyday human concept of time, where you would say every event happens at a precise number of seconds past midnight and you can always work out which happened first. That concept is problematic to implement in computers, because it's simply impractical for physically separated processors to have perfectly synchronised nanosecond-precision clocks and to attach timestamps to every message they share. So we throw away that concept of time and time-lines and define a brand new concept (called "happens before", but could equally be called "op" or "→") from scratch.

The axioms are trying to define that new concept with the minimal set of requirements on where there must be a well-defined ordering between events, so it's just barely strong enough to achieve the goal (in this case to define some useful kind of synchronisation between concurrent threads). And in this particular case, transitivity is one property that is required else the mathematical proofs stop working, so it has to be stated explicitly in the definition.


to post comments

An introduction to lockless algorithms

Posted Feb 20, 2021 18:12 UTC (Sat) by Wol (subscriber, #4433) [Link] (3 responses)

This is where relativity helps :-)

Whether two things are sequential or not depends on whether one occurs INSIDE the light-cone of the other. These acquire-release semantics force the two light cones to intersect, so anything after the intersect is visible inside both light cones so you can conclude they are sequential.

And the light-cone thing also explains why things can only be simultaneous if they occur at the same 4-dimensional co-ordinates, because otherwise they are not in each other's light cone, and therefore there is no mutual concept of time.

Cheers,
Wol

An introduction to lockless algorithms

Posted Feb 20, 2021 19:14 UTC (Sat) by pbonzini (subscriber, #60935) [Link] (2 responses)

I don't think it's really about relativity; anything that you can model as a directed graph function just as well as a representation of a partial ordering.

For example think of two cars going from A to B along two different roads. Any time a junction joins the two roads you *might* be able to say who is ahead at that moment. However while the roads are running parallel it's possible (but not certain) that you cannot say that. That is because the points along the two routes form a partial ordering.

An introduction to lockless algorithms

Posted Feb 21, 2021 12:36 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

No I didn't mean to say it was relativity. It's just that if you understand light cones and all that, it's the same problem in a different domain :-)

The send-receive creates a new light cone for which the origin is visible in both the previous two cones :-)

Cheers,
Wol

An introduction to lockless algorithms

Posted Feb 21, 2021 13:00 UTC (Sun) by pebolle (guest, #35204) [Link]

I'll file this under 'Disagreeing what "work" means'.

An introduction to lockless algorithms

Posted Feb 23, 2021 1:06 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

It's perfectly acceptable for there to be no ordering between them (except where the axioms say there must be an ordering).

From a practical standpoint, it's not just acceptable for there to be no ordering; it's actually desirable for performance. If you can divide up your program into separate tasks that don't have ordering constraints between them, you can run those tasks however makes the best performance sense. This has been the key to all kinds of modern performance advances, like out of order execution, multiprocessing, and what have you. Those things all depend on being able to break up tasks into parts that can be run in different orders. It's the need to synchronize that slows things down.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds