[bumper_crop]

One of the things that made linearizabilty click for me was thinking in terms of happens-before:

    volatile int a;
    a = 1;
    print(a) // Could this print Zero?

Even assuming only one program, one thread, one process, no interleaving and nothing fishy, could the final line print 0? In the serializable consistency, the answer is yes. Linearizability is framed in terms of clocks, but really that's just trying to establish that one thing happened before another. The "clock" in this example is the line number.

[penguin_booze]

I probably don't know enough about the topic, but am curious: isn't serializable an alias for 'strictly sequential execution'? If so, given your constraints, shouldn't it always print 1? I.e., the effect of setting a to 1 is visible to all subsequent statements, as if there were a barrier after every statement?

Regardless, could you comment on if and how different linerizable interpretation would be?

[singron]

It's covered in the article, but serialization just has to appear to execute in any sequential ordering of transactions. There are no other constraints about the ordering, so it technically allows the print to appear to run before the assignment.

Linearizability says that if A happens after B in real time (e.g. you don't start A until you get confirmation that B completed), A must see the effects of B. This would require the print to run after the assignment takes effect.