[erlang-questions] Does erlang:now() guarantee that subsequent calls to this BIF returns continuously increasing values even in erlang cluster?

[Michael Turner]

"Lamport/vector clocks and other similar ones operate on *causality*, but
this partial ordering is not the only one available or workable."

Whether it's "workable" depends on what's desired. Sorting by {Node,
Timestamp} is not accurate if causality matters and clocks have drifted out
of synch. As they will. Hence Lamport's work, and the work of others. And
if causality doesn't matter, well, I wonder: why bother? Unless you just
want a rough idea of when certain things happened, in which case {Node,
Timestamp} can give you a /total/ order that's, if anything, more accurate
than what you need.



Regards,
Michael Turner
Executive Director
Project Persephone
K-1 bldg 3F
7-2-6 Nishishinjuku
Shinjuku-ku Tokyo 160-0023
Tel: +81 (3) 6890-1140
Fax: +81 (3) 6890-1158
Mobile: +81 (90) 5203-8682
turner@REDACTED
http://www.projectpersephone.org/

"Love does not consist in gazing at each other, but in looking outward
together in the same direction." -- Antoine de Saint-Exupéry

On Mon, Apr 20, 2015 at 11:51 PM, Fred Hebert <mononcqc@REDACTED> wrote:

> On 04/20, Michael Turner wrote:
>
>> If you can make do with a partial order rather than a total order,
>> somehow:
>>
>>   http://www.erlang.org/doc/man/seq_trace.html
>>
>> Basically, Lamport clocks.
>>
>>
> Lamport clocks are one form of it. Sorting by {Node, Timestamp} also gives
> you a partial order. So do vector clocks and version vectors, interval tree
> clocks, and so on.
>
> Lamport/vector clocks and other similar ones operate on *causality*, but
> this partial ordering is not the only one available or workable.
>
> You could have them operating on users, nodes, shards, clusters,
> geographical regions, customers, or any other partitioning mechanism
> desired, for example.
>
> It's important to look at the system and its desired properties to be able
> to figure out which constraints allows us to best fit it to find the most
> appropriate solution possible.
>
> Regards,
> Fred.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150421/df34c909/attachment.htm>