<< Chapter < Page Chapter >> Page >

The awkwardness stems from the fact that in English, ``eventually'', ``always'',and ``until'' are primitives. When we design a formal language to capture with these concepts,shouldn't we too include them as primitives? Having our formal representations reflect ournatural conceptions of problems is the first law of programming!

This is why we have decided to incur the overhead of defining a new language, LTL.Still, you have noticed that the semantics we've given are phrased in terms of `` i . ''. From a language designer's perspective, we might say thatLTL is a high-level language, and we give an interpreter for it written in first-order logic(over the domain of trace-indices).

Translating between english and ltl: examples

Let's look at how to turn a natural-English specification intotemporal logic, and vice versa.

How might we express the common client/server relationship ``if there is a request ( r ), then it will be serviced ( s )''?

Hmm, that seems obvious: ( r s ) should do it, no? Alas, no. The problem is, the truth of thisformulawhich has no temporal connectives at allonly depends upon the trace's initial state, 0 in this case, whether 0 ( r s ) . This certainly doesn't match our intent, sincewe want the request and service to be able to happen at points in the future.Let's try again

Does the formula ( r s ) capture the English notion``if r is true, then s will be true''?

That's only a bit better: it does now allow the implication ( r s ) to hold in any state i . But our intent is to allow the servicing s to happen after the request r . The formula as given only expresses``Whenever r is true, then s is also true at that moment.'' If r and s both hold at the same time (which wouldn't be surprising),then ( r s ) fails for that trace.

After more thought, we can get something which does arguably match our intent: ( r s ) . ``Whenever a request is made, a servicing willeventually happen.''

However, even this may not be what everybody wants. Some considerations:

  • Even if r is raised (and lowered) several times, a single moment of s can satisfy the entire trace. This matches an intuition of r indicating a single ring of a telephone (and s being `pick up the phone'), but may not match the intuitionof r being ``leave a voicemail'' (and s being ``respond to a voicemail'').
    A trace showing multiple requests followed by a single servicing.
  • A trace in which s is always true (regardless of r ) certainly satisfies . Did you expect the English statement to encompass this?
  • Any trace in which requests are serviced instantaneously will satisfy . While this might be intended, it might alsobe a bug of leftover servicings from previous requests.
    A trace showing multiple requests and a single servicing. The servicing arguably corresponds toonly the first request and might be an undesired behavior.
  • A trace in which a request is never made still satisfies this formula.While that is probably what is intended, it may not have occurred to you from the English statementalone.
One advantage to having a formal language is that because the semantics are precisely defined,it helps us think about corner cases such as the above (and, gives an unambiguous meaning to the result,good for writing specs).

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Model checking concurrent programs. OpenStax CNX. Oct 27, 2005 Download for free at http://cnx.org/content/col10294/1.3
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Model checking concurrent programs' conversation and receive update notifications?

Ask