Our first goal is to deal with the last rule

    Some common time is neeced (e.g. make)

    Hardware doesn't supply it.

    So software must.

For isolated uniprocessor all that really matters is that the clock advances
monotonically (never goes backward).

    This says that if one time is greater than another the second
    happened later than the first.

For isolated multiple processor system need the clocks to agree so
if one processor marks one file as later than a second processor marks
a second file, the second marking really did come after the first.

Processor has a timer that interrups periodically.  The interrupt is
called a clock tick.

Software keeps a count of # of ticks since a known time.

    Initialized at boot time

Sadly the hardware used to generate clock ticks isn't perfect and some
run slightly faster than others.  This causes CLOCK SKEW.

Clocks that agree with each other (i.e. are consistent, see below) are
called LOGICAL CLOCKS.

If the system must interact with the real world (say a human),
it is important that the system time is at least close to the real
time.

Clocks that agree with real time are called PHYSICAL CLOCKS

Logical Clocks

    What does it mean for clocks to agree with each other?

    For logical clocks we only care that if one event happens before
    another, the first occurs at an earlier time ON THE LOCAL CLOCK.

We say a HAPPENS BEFORE b, written a-->b if one of the following holds

    1.  Events a and b are in the same process, and a occurs before b.

    2.  Event a is the sending of msg M and b is the receiveing of M.

    3.  Transitivity, i.e. a-->c and c-->b

We say a HAPPENS AFTER b if b happens before a.

We say a and b are CONCURRENT if neither a-->b nor b-->a

HOMEWORK 11-1

We require for logical clocks that  a-->b implies C(a) > C(b), where
C(x) is the time at which x occurs.  That is C(x) is the value of the
local clock when event x occurs.

How do we insure that this rule (a-->b implies C(a) > C(b)).  We start
by using the local clock value, but need some fixups.

    Condition 1 is almost satisfied.  If a process stays on a
    processor, the clock value will never decrease.  So we need two
    fixups.

        If a process moves from one processor to another, must save
        the clock value on the first and make sure that the second is
        no earlier (indeed it should probably be at lease one tick
        later).

        If two events occur rapidly (say two msg sends), make sure
        that there is at lease one clock tick between.

    Condition 2 is NOT satisfied.  The clocks on different processORs
    can definitely differ a little so a msg might arrive before it was
    sent.

    The fixup is to record in the msg the time of sending and when it
    arrives, set local clock to max (local time, msg send time + 1)

    The above is Lamport's algorithm for synchronizing logical
    clocks.

More information on logical time can be found in Raynal and Singhal
IEEE Computer Feb 96 (we are NOT covering this).

    The above is called SCALAR TIME.

    They also have VECTOR TIME and MATRIX TIME

        In vector time each process P keeps a vector (hence the name) of
        clocks, entry i gives P's idea of the clock at Pi.

        In matrix time each process keeps a (guess) matrix (correct!)
        of clocks.  Idea is that P keeps a record of what Q thinks R's
        clock says.