[erlang-questions] Lamport/logical clocks?

Scott Lystig Fritchie fritchie@REDACTED
Tue May 29 06:17:59 CEST 2007

Greetings to all in distributed computing land.  I was about to do
some coding for a Lamport/logical clock ... because I need one and
it'd be easy to write ... but then stopped myself and decided to look
for prior Erlang art.

Armed with "grep" and a deadline before I needed to start cooking
supper, I didn't find much.

The closest that I've found is in the 'seq_trace' module in the
'kernel' OTP docs(*).  The "Serial" value described there looks
remarkably like a Lamport clock.  The fact that that serial # is
attached "for free" to all suitably traced processes is nifty...

1. ... except that seq_trace at the shell doesn't seem to work
correctly.  All of the trace flags are reset to their defaults
after/before? each shell command.  The same thing happens for send,
'receive', print, and label.

    (foo@REDACTED)5> self().
    (foo@REDACTED)6> seq_trace:set_token(print, true).
    (foo@REDACTED)7> seq_trace:set_token(print, true).
    (foo@REDACTED)8> seq_trace:set_token(print, true).
    (foo@REDACTED)9> self().                          
    (foo@REDACTED)10> [ io:format("~p\n", [seq_trace:set_token(print, true)]) || _ <- lists:seq(1,5) ]. 
    (foo@REDACTED)11> seq_trace:set_token(print, true).                            false
2. It looks like none of the apps bundled with OTP are using the
seq_trace Serial value of the Lamport clock for event sorting?

Inviso uses the (optional) timestamp, but that's the erlang:now()
value, and even an NTP time sync may not be good enough for a busy
system to avoid bogus event ordering.  I have enough problems with NTP
on or lab machines -- it shouldn't be hard, but apparently it is,
because their NTP daemons aren't running 1 time in 8.

Don't get me started about time drift in Linux virtual machines,
VMware and Xen both.  {sigh}

3. Have some docs drifted out of sync, like the ET app's User's Guide
saying "In the Megaco application of Erlang/OTP, the code is carefully
instrumented with calls to et:report_event/5." when "grep" couldn't
find a single one?


More information about the erlang-questions mailing list