[erlang-questions] Lamport/logical clocks?

[Kenneth Lundin]

On 5/29/07, Scott Lystig Fritchie <fritchie@REDACTED> wrote:
> 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...
>
The serial used in sequential tracing (seq_trace) is indeed working as a
Lamport clock.
Seq_trace is the support for sequential tracing and the the purpose
with the serial is to enable correct ordering the trace events.
The serial is not to be used for any other purposes than the ordering of
sequential trace events.
With sequential tracing it is possible to follow a "trace" from start to end
passing many different processes and the "trace" will not be disturbed by
any other events possibly handled by the involved processes.

> 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.

seq_trace works like this:
If the trace_token is set for a process A it will contaminate other processes
with the trace_token as well when A sends a message to another process.
If process A receives a message where the trace token is not set it's own
trace token will be reset automatically.

This is what happens when you set the trace token in the shell (for
the shell process). Before the next prompt the shell process will have
received
one or several messages without trace token and thus the trace token is reset.

You can try the following sequence in the shell to see that it actually works.

1> seq_trace:set_system_tracer(self()).
false
2> seq_trace:set_token(send,true).
false
3> flush().
Shell got {seq_trace,
              0,
              {send,
                  {0,1},
                  <0.24.0>,
                  <0.23.0>,
                  {io_request,<0.24.0>,<0.23.0>,{put_chars,<<"false">>}}}}
Shell got {seq_trace,0,
                     {send,{1,2},
                           <0.23.0>,
                           <0.21.0>,
                           {<0.23.0>,{put_chars,<<"false">>}}}}
Shell got {seq_trace,0,{send,{1,3},<0.23.0>,<0.24.0>,{io_reply,<0.23.0>,ok}}}
Shell got {seq_trace,0,
                     {send,{2,3},
                           <0.21.0>,
                           #Port<0.64>,
                           {<0.21.0>,{command,[0|<<"false">>]}}}}
Shell got {seq_trace,0,
                     {send,{3,4},
                           <0.24.0>,
                           <0.23.0>,
                           {io_request,<0.24.0>,<0.23.0>,{put_chars,"\n"}}}}
Shell got {seq_trace,0,
                     {send,{4,5},
                           <0.23.0>,
                           <0.21.0>,
                           {<0.23.0>,{put_chars,<<"\n">>}}}}
Shell got {seq_trace,0,{send,{4,6},<0.23.0>,<0.24.0>,{io_reply,<0.23.0>,ok}}}
Shell got {seq_trace,0,
                     {send,{5,6},
                           <0.21.0>,
                           #Port<0.64>,
                           {<0.21.0>,{command,[0|<<"\n">>]}}}}
ok
4>

This is a sequential trace over what happens in the shell process immediately
after that the seq_trace_set_token(send,true) has been executed.
In this case tracing only on sent messages (send,true) as a result of
the printout handling in the shell.

/Kenneth


>
>     (foo@REDACTED)5> self().
>     <0.38.0>
>     (foo@REDACTED)6> seq_trace:set_token(print, true).
>     false
>     (foo@REDACTED)7> seq_trace:set_token(print, true).
>     false
>     (foo@REDACTED)8> seq_trace:set_token(print, true).
>     false
>     (foo@REDACTED)9> self().
>     <0.38.0>
>     (foo@REDACTED)10> [ io:format("~p\n", [seq_trace:set_token(print, true)]) || _ <- lists:seq(1,5) ].
>     false
>     true
>     true
>     true
>     true
>     [ok,ok,ok,ok,ok]
>     (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?
>
> -Scott
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>