11.1 How to Think about Time

Each concurrently executing object has its own lifeline, which can be synchronized with others by sending signals. This formulation leaves open the question of what "time" on an object lifeline means for each instance.

Consider an object A that sends a signal X to an object C. Once C receives X, it sends a signal Z to B. Object A also immediately sends a signal Y to B. What is the order in which signals arrive at B? Does Y arrive at B first? Or Z?

The Executable UML formalism does not say. There are no rules about the order of receipt of Y and Z, so both of the sequences in Figure 11.1 are legal.

Figure 11.1. Concurrent Signals

This view of time is similar to Einstein's relativistic view of time. If we transmit a signal to two stars, one which in turn transmits a signal to our second star, it is not known which signal will arrive at the second star first, only that if we send two signals to a single star the signals will arrive in the order we sent them.

The issue extends beyond signal sending to the general question of duration and time. When an instance wants to cause another instance to do something "at three o'clock," how can the two instances agree on when three o'clock actually is? This is a thorny topic in distributed computing and is comprehensively addressed in [1]. Lamport concludes that clock synchronization is not possible, and that each processor can assert reliable statements only about an object lifeline against which it can assign times that do not synchronize with other clocks. In other words, Lamport asserts the Einsteinian view taken by Executable UML.