Page 72. This page is in the page-by-page raw-dumps section.


((There is only the Fig.3.10 on that page 72, supposedly representing a monitor with two procedures.))

((General Commentary on i/o logic: If you have ever used (or seen) SARA (UCLA graphs), the discussions about input logics may not be foreign. It is the same, but with confused specified meaning, and/or faulty implementations, in the way the copycat82 has adopted them.))

((I have circled the input places for the procedures, with the place below the C1 The former are "++-in"ed between themselves, and "xor-in"ed with the latter. eep in mind that, the copycat82 defines "xor-in" becomes permanently blocked, once both of its input places are enabled. See.p.46. I had criticized this, and here is an example.)) This is telling the C1 should be deadlocked if the in-monitor procedure(s) complete, and also there are some new requests coming, then. The "xor-in" could be an "and-in" to correct this. But then, the first start-up would be dead-on-start, with this configuration, with no tokens at that place, and no incoming tokens before the procedures run at least once. (I do not even discuss the weird possibility, which is enabled by this specification, that the "initialization" code uses one of those two available-for-calling procedures.)

This is not the single example for such wishful using of the "xor-in"-deadlock-out :-) by the copycat82. In the text, on page 70, it suggests there can be no re-activation of C1, and then does this. In fact, by the very nature of "++-in", not to mention the "as soon as" suggestion, the re-activation is unavoidable. That is why, I have written "if the request arrives then". Yet, if we take the text at its words, this deadlock is unavoidable. There is no way to run. The only thing left is that the nice users of that monitor would never make such a request, and only then, no error would surface.

((The place, above C1, is also "xor-in"ed with those others)) All the same may happen, if the environment in question, if there can be any requests before the activation enabled by the place labeled "initialize" completes. ((See the relevant discussion in the text on page 70, where there are more to tell about.))

Further Reading

(page-by-page raw-dumps section) . . . . . previous . . . . . next

Forum: . . (Fair Menu . . . . . Fault Report? . . . . . Remedy for your case . . . . . Noticed Plagiarism?)

Referring#: 0
Last-Revised (text) on June 10, 2004 . . . that was
mirror to, on June 18, 2009
Written by: Ahmed Ferzan/Ferzen R Midyat-Zila (or, Earth)
Copyright (c) 2004, 2009 Ferzan Midyat. All rights reserved.