07.01.2013 Views

Lecture Notes in Computer Science 3472

Lecture Notes in Computer Science 3472

Lecture Notes in Computer Science 3472

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

s<br />

a b<br />

t<br />

5 Preorder Relations 133<br />

y<br />

a b<br />

Fig. 5.6. Processes equivalent under observation preorder (s �B t; s �R t; s ��must t;<br />

s �fmust t).<br />

the state, so no matter how many times we go through it we end where we left<br />

from. Still, the τ-loop is not without significance <strong>in</strong> practice s<strong>in</strong>ce such a loop<br />

may produce divergence (if the process keeps iterat<strong>in</strong>g through it). However, it<br />

can also be argued that the τ-loopisexecutedanarbitrarybutf<strong>in</strong>itenumberof<br />

times and so the process executes b eventually (under some notion of fairness).<br />

We shall actually argue back and forth about these two processes as we go along<br />

with the description of other preorder relations, so you do not have to make up<br />

your m<strong>in</strong>d just yet.<br />

5.5 Test<strong>in</strong>g Preorders<br />

Test<strong>in</strong>g preorders [dNH84] are coarser than observation preorder. Essentially,<br />

test<strong>in</strong>g preorders differentiate between processes based on differences <strong>in</strong> deadlock<br />

behavior. We may differentiate by the ability to respond positively to a test, or<br />

the ability to respond negatively to a test, or both. In practical cases this is often<br />

sufficient.<br />

Recall the concept of outcome of a test presented <strong>in</strong> Section 5.2.2. For a test<br />

o and a process p the result of apply<strong>in</strong>g o to p is the set of runs Runs(o, p)<br />

with outcomes from the set {⊥, ⊤}. Also recall the lattices Pmay, Pmust, and<br />

Pconv over the powerset of {⊥, ⊤}, together with the correspond<strong>in</strong>g partial order<br />

relations.<br />

We then have the follow<strong>in</strong>g test<strong>in</strong>g scenario for test<strong>in</strong>g preorders: We run<br />

a test <strong>in</strong> parallel to the process be<strong>in</strong>g tested, such that they perform the same<br />

actions. If the test reaches a success state, then the test succeeds; if on the other<br />

hand the process reaches a deadlock state (i.e., a state with no way out), or if<br />

the process diverges before the test has reached a success state, the test fails.<br />

Sometimes we are <strong>in</strong>terested <strong>in</strong> runn<strong>in</strong>g the same test repeatedly and collect all<br />

of the possible outcomes; we need this when we want to make sure that a test<br />

succeeds no matter what.<br />

Formally, we change <strong>in</strong> what follows (simplify <strong>in</strong> fact) the semantics of Expression<br />

(5.3) from Def<strong>in</strong>ition 5.4 on page 125 to<br />

obs(ao, p) = � {obs(o, p ′ ) | p a ⇒ p ′ }∪{⊥|p ↑} ∪ {⊥ | p �⇒} (5.11)<br />

Then we look at two alternative ways to restrict the set of tests O:<br />

(1) Let Omay be def<strong>in</strong>ed only by expressions of form (5.1), (5.3), and (5.5). We<br />

do not need any test that signifies failure; <strong>in</strong>stead, failure under test happens<br />

τ

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!