Access to the Monitor

Program X, the various dX elements, and the communication buffers comprise "a collection of procedures and data which together control the manipulation of some resource" - namely, the c ommon data. This was the first part of the informal definition of a monitor given in section 4.1 where, however, two further constraints were laid down - that the resource could only be accessed via the monitor, and that execution of the monitor procedures is mutually exclusive in time. The first of these constraints is clearly satisfied, since the common data is only directly accessible by program X; however it is clearly possible for several d X elements to be active at the same time, and we must examine this aspect in more detail.

Let us consider what happens when program A wishes to communicate with program X. First it will call the appropriate procedure within its dX element; this will place a message in the message buffer; finally, if no reply is expected it will return control to program A, otherwise it will wait for a reply.

Now let us consider program X. When it receives the message from program A it must either store some data and send no reply, or it must take some action and send a reply, or it may wish to suspend program A by not sending a reply when one is expected. In the first two cases it cannot move on to the next message in its buffer until it has completed processing the message from program A; we can therefore consider the requirement for mutual exclusion to have been met so far as program X is concerned.

However in the third case the processing of the message from program A is not completed as a reply has yet to be sent; nevertheless program X must proceed to the next message.

84

-At some subsequent point in time the conditions necessary for re­

activation of program A will be satisfied. However, if a reply to the original message from program A were then to be sent two problems would arise. The first of these is that some undesirable interaction might occur between the two programs which were simultaneously "active" with respect to program X, while the second is that all the details of the original message would need to be preserved. We can avoid both of these problems by returning,a special reply to program A requesting it to re-transmit the original message. This clearly avoids the need for program X to store the message, and it also eliminates the possibility of interaction since the re-transmitted message will be processed in the usual manner when it reaches the head of the queue. We may therefore consider that during its period of suspension program A is not active with respect to program X, because the original message has, in effect, been rejected and must be transmitted. The requirement for mutual exclusion is therefore satisfied for all situations.

We now have a method whereby both access to data and synchronisation can be controlled in an orderly fashion; however we must take one further step before we have a sufficiently sound system for general use, since the

"monitor" will only operate correctly if a number of conventions are observed - notably those discussed above in connection with suspension and re-activation. In order to ensure that these conventions are observed we define a set of higher-level procedures operating on user-identifiable items such as, for example, PUT LINE, GET RECORD, STORE DATA, etc. These procedures will use the low-level procedures already discussed to carry out communication with program X and will be the only "monitor procedures"

available to the user programs (A,B,C, etc.). Thus these programs need not know of the existence of program X and the associated communication procedures, but will merely call appropriate procedures to carry out specified activities such as input, output, and access to common data. The complete system structure may now be represented as shown in figure 4.5, where the circular form has been used to indicate that none of the user programs need have any particular significance

Figure 4.5 A dispersed monitor

The shaded area within each of the user programs represents the high- level monitor procedures which, alone, are accessible to the user program.

The area enclosed by the dotted circle will henceforth be referred to as the dispersed monitor.

The really important feature of this concept is that because each program communicates with the rest of the system (including common data areas) only through simple, easy-to-understand, procedures it provides a very powerful tool for the provision of easily adaptable software - which was one of the primary objectives of this research. This is because program X, or the Executive module as we shall henceforth refer to it, need know little or nothing about the activities of the other programs (or modules), and they in turn need know nothing about each other.

The Executive module must, of course, know of the existence of the other modules; however, as long as there is no over-riding priority between the user modules it need know nothing about their purpose or how they achieve it. It will, of course, have a full knowledge of the common

86

-data, as well as of a number of other matters of global interest;

similarly the high-level monitor procedures will be designed to reflect the particular application both in terms of the data and of any specific synchronising philosophy. However, in neither case does this reflect a knowledge of an individual module, but merely of the overall system structure and purpose.

It is therefore possible to add or remove modules from the system at will, subject only to the requirement that the Executive module should be informed (for example, by means of initialisation parameters) of the names or other identifying characteristics of the modules to be used for a given computer run. The practical effect of this is obvious and far-reaching in its implications; in particular, it allows the testing of new facilities without in any way affecting those parts of the system which are unchanged, and it enables the system to be restructured in a dynamic fashion to suit the particular set of input data to be processed.

A further benefit which ensues is that automatic generation of user modules to process new facilites becomes relatively straight-forward, since the interface between the new module and the remainder of the system is well defined and can be built into a generator program without much difficulty. Chapter 6 will investigate this aspect of the research.