GB2204432A - Multiple processor networks - Google Patents

Abstract

In a multiple processor data handling network, each processor has access to at least one associated peripheral device 12, 14, 16, 18, 20 under the control of a respective handler 22, 24, 26, 28, 30, 32 of the operating system of the processor. Also each processor has access to the peripheral device(s) associated with a second or further processors of the network through a data transmission link, 34, such that, on receipt by the operating system of any one of the processors of a request for access to a given peripheral device which is not available for direct access by the one processor through its own operating system, that processor activates and controls, via the data transmission link the handler of another processor to which the given peripheral device is available. <IMAGE>

Description

Multiple Processor Networks This invention relates to data handling systems in which a plurality of programmed processors are linked together to form a network to allow access of each processor to peripheral devices associated with the other processor(s) of the network whereby the number of peripheral devices available to each processor can be expanded.

According to the present invention there is provided a multiple processor data handling network in which each processor has access to at least one associated peripheral device under the control of a respective handler of the operating system of that processor and has access to the peripheral device or devices associated with a second or further processors of the network through a data transmission link such that, on receipt by the operating system of any one of the processors of a request for access to a peripheral device which is not available for direct access by said one processor through its own operating system, that processor via the data transmission link can activate and assume control of the handler of another processor to which the given peripheral device is available.

A feature of the invention resides in the networking of the peripheral device handlers. In this way, whilst a master-slave relationship may be established at the handler level in the operating system hierarchy of the slave processor, the processors remain independent of each other at the monitor level of their operating systems. This is in contrast with one known form of network in which information relating to a particular peripheral device is transferred from the operating system of a processor which requires access to that peripheral device to the operating system of the processor to which the peripheral device is actually directly connected.

In order to gain access to and control of a handler associated with the given peripheral device, said one processor is conveniently arranged to output an identification code identifying the peripheral device it requires and the identification code is routed by the data transmission link to all of the data inputs of all of the other processors of the network, each processor being arranged to recognise identification codes applicable to the peripheral device or devices to which it has access via its own handler(s) and, on such recognition, output an acknowledgement code via the data link whereby a master-slave relationship is set up between said one processor and any processor acknowledging the identification code thus enabling the master processor to output data via the data link directly to the corresponding handler of the slave processor and hence to the given peripheral device.

In operation therefore, the user of a particular processor in the network may access any of the peripheral devices within the network, all of the peripheral devices appearing to the user (and also to the programs and system utilities of the user's processor) to be on the user's processor.

One embodiment of the invention will now be described by way of example only with reference to the accompanying drawing in which: Figure 1 shows in diagrammatic form two computers, with connected peripheral devices, forming part of a multiple computer network in accordance with the invention, the computers being illustrated in terms of their user, monitor and handler software implementation and two computers only being illustrated for the sake of simplicity; and Figure 2 is a block diagram of the data link hardware.

As shown in Figure 1, each computer 1, 2 comprises a user-software section 10A, lOB which, in use, will give rise to data which will need to be transferred to peripheral devices, such as discs, printers, plotters, displays etc. Computer 1 has two peripheral devices 12, 14 associated with it whilst computer 2 has three associated peripheral devices 16, 18, 20. Read/write transfer of data between each computer and the associated peripheral devices is effected under the control of the monitor or supervisor software 20A, 20B of the operating system of the respective computer whch calls up the appropriate handler or driver software 22, 24, 26, 28, 30, 32. In the absence of networking, each computer 1, 2 has access only to those peripheral devices that are directly linked to it.To expand access of each computer to a wider range of peripheral devices, the computers are linked together in a network to allow data transfer to take place via a data transmission link 34 to which each computer is coupled through a software-controlled interface 40A, 40B the functioning of which will be described in greater detail hereinafter.

For the sake of example only, the following description of Figure 1 is given on the basis that the peripheral device 12 is a visual display, device 14 is a disc drive loaded with a disc embodying a particular set of files, device 16 is a printer, device 18 is a disc drive loaded with another disc embodying a different set of files and device 20 is another display. If computer 1 , via its user software 10A, receives a read/write request for access to a file available on the disc of drive 14, the request, together with various parameters to be described hereinafter, is processed by its monitor 20A. The processing procedure will involve calling up the handler 26 associated with disc drive 14 and interrogating (see logic symbol 36) the handler 26 to check whether or not the required disc is available.If the result of interrogation is YES the information read/write request is processed in a conventional manner through the handler 26.

It will be noted from Figure 1 that the software of computer 1 includes a handler 24 which is not associated with any of the peripheral devices connected to computer 1. In practice, each computer may have a number of such handlers each associated with a particular peripheral device which, though not directly connected to that computer, may be available elsewhere within the network.

Thus, for example, the handler 24, at least as seen by the monitor 20A, may be suitable for handling read/write requests to the disc loaded in disc drive 18. As will become apparent hereinafter, it is not necessary for the handler 24 to include all of the facilities of handler 30. All that is required is for the handler 24 to simulate the handler 30 to the extent necessary to enable the monitor 20A to interrogate (see logic symbol 38) handler 24. In this case, the result of such interrogation will be NO and, as a consequence, the request is routed via output bus 42A and interface 40A to the data link bus 34. By means of a protocol to be discussed hereinafter, the monitor 20A may gain control of the data link bus 34 thus enabling it to link up with the handler of any other processor in the network which is associated with the required disc; in this case the link with the handler 30 via data input bus 44B of computer 2. On establishment of this link, the monitor 20A of computer 1 is in direct communication with the handler 30, ie communication takes place independently of the monitor 20B of computer 2, all of the parameters required by the handler 30 for control of, and data exchange with, the disc drive 18 being provided directly by the monitor 20A.

A block diagram of the hardware for the data link is shown in Figure 2 which allows any two processors 20A, B, C . . . (here shown as Digital PDP11/LS11) to be cross connected via a bus 34 in a simplified situation where simultaneous input and output are not required thus allowing use of a single data bus 34 for both input and output. A protocol is required to gain use of the bus and set up the cross connection between two processors.

The following protocol is used: l. When a processor 50A, B, C . . . requires use of the bus 34, it asserts the 'bus request' line. This requires each processor parallel interface 52A, 52B, 52C. . . (eg type DRV 11 parallel interface) to have the facility to output an additional bit in addition to the data bits.

2. When the bus controller 53 detects that the bus 34 is free, it uses a conventional daisy chain arbitration to give control to the nearest interface to the controller that is requesting use of the bus. Thus, the bus controller 53 outputs a 'grant' signal to the first interface 54A on the bus. If this interface is not requesting use of the bus, it passes the 'grant' signal on to the next interface 54B etc in a 'daisy chain'. If an interface is requesting use of the bus, it blocks the 'grant' signal passing to the next interface and sends a signal to the controller 53 acknowledging that it has accepted the 'grant'. If the controller 53 fails to receive an acknowledgement, an error state, it retransmits the 'grant' signal. This interface/processor is now the 'bus master'.

3. The bus controller 53 then sends a unique code to the data input of the 'master' processor. On reading this data word, the processor recognizes that it now is the bus 'master' and so outputs a unique 'request word' describing the function it requires (eg access to a certain file on a disc or access to a particular display or printer).

4. The 'request word' is routed to all the data inputs of all the other processors.

5. If a processor recognizes the 'request word' as a function that it can supply, it outputs a data word that is routed to the data input of the 'master' processor.

The process of outputting a data word at this time makes the processor the 'slave'. The presence of a data word at the 'master' processor input indicates to the 'master' processor that its 'request word' has been acknowledged.

The form of this data word is immaterial to the hardware but in practice would probably include the identity of the 'slave' processor.

6. The logic in the interfaces now cross connects the 'master' and 'slave' processors so that data output by the 'master' is routed to the data input of the 'slave' and vice-versa. The data lines to all the other processors are disabled. The only difference between the 'master' and 'slave' is that it is only the 'master' that can terminate use of the bus. This it does by negating its 'bus request' signal.

7. Only one processor can place data on the bus at a time. If a second processor tries to place data on the bus 34 while a first processor has data on the bus for the second processor the output attempt by the latter processor will be blocked until it reads the data that is being sent to it. All processors should therefore accept input data, even if it is not expected, so as to prevent the system hanging if the system gets out of step.

The above protocol allows commercial parallel interfaces to be used provided they have handshakes and the ability to output an extra bit (required to request use of 'bus'). For the 'QBUS' series of Digital PDP11 computers, LSI11, the DRVl1 or DRV1lB or DRV11W satisfy this requirement. For the 'UNIBUS' PDP11 computers there are the DR11C or DR11B or DR1lW. The range of request codes, about 64K, should meet any requirement. The hardware does not require the requesting processor, the 'master', to know where the peripheral is on the system.

If required, a specific processor can be requested by allocating certain request codes in the software.

The following is a brief description of the software with reference to Digital PDP11 computers running a RT11 or TSX+ operating system. It is assumed that the reader is familiar with the RT11/TSX+ operating systems, and in particular handlers. The RT11 (or TSX+) monitor calls a handler with the information describing the transfer, read/write, number of words, address of user buffer, position on disc (ie 'block number') etc in an area of memory called the 'queue element'. A mechanism has been developed to patch a handler so as to add extra code on entering the handler, called the 'entry mod.' and when exiting the handler called the exit mod.'.The 'entry mod.' checks if the required peripheral unit is present on the associated processor using a table that is set up when the software is initialised. If the peripheral is present on this processor, a 'busy' flag is set and the handler code is executed as normal while if the peripheral is not present, the request is sent to the 'data link'. The 'busy' flag is used to prevent the 'data link' using the handler while the monitor is using the handler. There is a further 'busy' flag that is tested by 'entry mod.' to block the use of the handler code by the monitor if the 'data link' is using the handler. The 'exit mod.' is used to clear the 'busy' flags and give use of the handler code to either the monitor or 'data link' if either is waiting.The software is introduced into the system as a handler with about 4 kbytes of code/tables and an I/O buffer (4 kbytes at present) giving a total of about 8 kbytes. In general, the code does not behave as a handler but as a 'job' that is invisible to the monitors.

The 'data link' is enabled by running a patching program with a control file. The control file is unique to each processor and defines which handlers are to be patched into the 'data link', which peripheral units are present on this processor and which requests from other processors should be accepted and to which peripheral should they be directed. Before anything is patched, a check is made that the handlers are as expected. By patching the 'normal' handlers, the requirement for additional versions of handlers for use with the data link are avoided. For a peripheral such as RKO5 disc drive to be accessed, there must be an RK handler on each processor. If there are no RKO5 drives on a processor, then all requests to RKO5 drives may be routed to the 'data link' and the actual RK handler code will never by executed. In such cases, memory space can be saved by using a 'special' RK handler consisting of a simplified null handler that always takes the error exit. If the 'data link' is in use, all requests to RKO5 units will be directed to the data link while if there is no 'data link', an attempt to use the non existent RKO5 will produce an error. A further reduction in memory and handler slots is possible using an 'assignment'. For example, on processors that do not have the DY floppy disc, DYO is assigned to RK4, a non existent device. A request to DYO is then converted to a request to RK4 which is in turn passed to the 'data link'. The processor with the DY floppy disc then accepts the RK4 request from the 'data link' and directs it to DYO.

Having obtained use of the 'data link hardware', as described with reference to Figure 2 a protocol is required to transmit the handler request and data. The protocol entails transmitting 'packets' of data, each with a checksum. Essentially, the protocol consists of a 'header packet' that defines the 'block No' on the disc and the number of words to transfer, a 'data packet' of up to 256 words and an 'acknowledgement packet'. If more than 256 words are to be transferred, the protocol is repeated. The 'header packet' also includes the total size of the transfer so that the 'data link software' can reduce the number of disc requests. Thus, if there was a request to read 9 blocks (of 256 words), the 'slave processor' on receipt of the request for the first block will fill its I/O buffer of say 8 blocks with the first 8 blocks and then transmit the first block.Following transfers can then be done without any disc access on the slave until the ninth block is requested. This process makes use of the RT11 contiguous file structure and the resulting handler capability of transferring up to 64K words at a time.

An example of how a handler XX can be patched into the 'data link' software is given in Table 1. The 'data link' software has a 'device table' that contains an entry for each handler that is patched into the system.

The information for each entry in this table includes which hardware units are present on this processor, the position in memory of the handler, including the position of the 'entry mod.' and 'exit mod.' and a status word for the various busy flags etc. It can be seen from Table 1 that both the 'entry mod.' and 'exit mod.' are implemented by a call to MOD, a routine in the 'data link' software. The routine MOD is not a subroutine, but a routine that uses the 'return address' and the 'device table' described above to determine which patch in which handler is being executed. Having patched part of the handler code with CALL@#MOD, a method must be provided to execute the overwritten code.The 'exit mod.' is implemented by overwriting the 7 word .DRFIN macro code and including the .DRFIN code in part of the 'data link' software, so provided the handler uses the .DRFIN macro there is no problem. Handlers that do not use the .DRFIN macro to exit are very rare. In the case of the 'entry mod.', a scheme whereby the first two words of handler code are relocated into a three word area in the overwritten .DRFIN macro has worked for all the handlers in our applications. Should a handler be found that is not amenable to this technique, then adding two NOP (no operation) instructions into the source at the start of the-handler code would then make the handler amenable.

When the monitor calls a handler, it has loaded a handler location, XXCQE in the case of the Table 1 example, with a pointer to the queue element. If the handler was in use by the 'data link', the 'entry mod.' code would queue the monitor request but only after the monitor has overwritten XXCQEI The solution is to further patch the handler so that all references to XXCQE are changed to XXCQ, a new location in the overwritten .DRFIN. Location XXCQ is then loaded with either XXCQE or a pointer to the 'data link' queue element before the handler code is executed.

The 'data link' software requires that all handlers that are networked are permanently loaded. Rut 11 handlers are written in position independent code and might be loaded anywhere in memory by the monitor. The actual patching of the handlers is performed by a small program using a control file. The control file is a table of numbers written in MACRO so that once it is compiled and linked, block 1 of the resulting file is an image of the table. Table 2 is an example of a Macro to produce control file data to patch the handler of Table 1.

Two macros, PATCH and PATCQ, have been written to simplify this macro. Provided a full listing of the handler is available, the procedure is quite straight forward. The handler listing assumes a zero starting address so all the addresses are offsets to the start of the handler. The executable code always starts at offset 10., label START in Table 1. As all handlers that are networked must be permanently loaded, the interrupt vector always contains the actual memory location of XXINT, the interrupt service routine. Including the interrupt vector address and the offsets to XXINT, A, DONE in the control file then provides the data for the patching program to patch the handler. The control file also includes a table of locations that reference XXCQE in the form of offset, normal value, patched value.

(Macro PATCQ generates this table). Before any handler patching is done, the patching program first checks that all the handlers are as expected, including the presence of .DRFIN code at the declared locations.

The 'data link' software assumes that all the processors have a number in the range 0-7, although this does not have to be unique. A request to the data link includes a 3 bit peripheral unit, a 6 bit code to define the peripheral and the 3 bit number of the requesting processor. This allows a reference to a certain peripheral name to be directed to a different actual peripheral depending on the processor. The 'data link' software has an 'ID table' to hold requests that are to be accepted by this processor and where to direct the request. There is also a write protect option. The write protect option can be applied to all the system discs so that only the processor that owns the system disc can write to it since there is a remote chance that two users might try and update the directory at the same time, resulting in a composite of two different directories.

Table 3 is the control file used on one of the processors. It is compiled with an additional file containing the Macro definitions. Besides Macros to provide data to patch the handlers, Macro JPHEAD provides data on the processor number, which compile options should have been included in the 'data link' handler, details of the parallel interface etc while Macros LIST and CROSS provide data for the 'ID table'.

TABLE 1 tOutline of a handler XX (before patching) .MCALL .DRDEF ;Macro .DRDEF defines default values for some parameters etc.

.DRDEF XX,etc.

Macro .DRBEG defines various locations, including XXCQE, a pointer to the queue element .DRBEG XX START: MOV #xXcNT,(Pc)+ RETRY: .WORD O A: etc.

MOV XXCQE,R4 RETURN ;Macro .DRAST defines the start of the interrupt sevice etc.

;Label XXINT is the start of the interrupt sevice DRAFT XX,5 etc.

macro .DRFIN generates 7 words of exit code DONE: .DRFIN XX ;Macro .DREND ends the handler code TREND XX .END After 'patching' the handler is equivalent to the following: .MCALL .DRDEF .DRDEF XX,etc.

.DRBEG XX START: CALL @&num;MOD ;first 2 words of code overwritten RETRY: .WORD O A: etc.

Change all references to XXCQE to XXCQ MOV XXCQ,R4 RETURN DRAST XX,5 etc.

;The 7 word .DRFIN macro code is overwritten DONE: CALL @#MOD XXCQ: .WORD O ;replaces XXCQE ;The next three words contain the equivalent of the first 2 words of code, MOV #XXCNT,RETRY, that were overwritten by CALL @#MOD. This code is called with the address of label A yon the stack.

MOV #XXCNT, .-6-DONE+RETRY ~MOV #XXCNT,RETRY relocated RETURN ;Go to A: .DREND XX .END TABLE 2 MACRO TO PATCH THE XX HANDLER ; MACRO XX5 UU ; Macro to patch the XX handler for RT11 V5 Z UU defines which units present on this processor where: bit 0=1 if unit 0 present bit 1=1 if unit 1 present etc Macro PATCH and PATCQ simplify this macro to: ; PATCH DEVICE=XX,UNITS=UU,VEC=a, XXINT=b, RMODA=c, DRFIN=d, INST= MOV *10,.-DRFIN-6+16 PATCQ 22,177764 PATCQ 114,177672 PATCQ 326,177460 PATCQ 0 ENDM ;Where the arguments to macro PATCH are: interrupt vector=a offset to interrupt service=b offset to label A=c offset to . DRFIN macro (at label DONE) =d assuming XXCNT=10 and label RETRY is at offset 16, the instruction ~ MOV *XXCNT,RETRY becomes MOV #10,.-DRFIN-6+16, where DRFIN has been defined as equal to 'd' by macro PATCH (N.B. MOV #XXCNT,.-DRFIN-6-RETRY cannot be used as the Macro does not know the values of XXCNT or RETRY) And macro PATCQ is used to change references to XXCQE to XXCQ Thus in this example, there is a reference to XXCQE in the region of offset 20 Offset 22 contains 177764, the offset word to XXCQE in the reference.

This will be amended to point to XXCQ A Azero argument to PATCQ terminates the list of changes TABLE 3 EXAMPLE OF CONTROL FILE ;Data link control file for floppy LSI11/23 RT11FB system JPHEAD 4,4 ~Processor 4, compiler option flags=4 ~RK ;Patch the RT11 V3B 'null type' RK handler RK3BNL 0 ;No RK units .WORD O ;End of RK DP ;Patch the RT11 V3B 'null type' DP handler DP3BNL 0 ;No DP units .WORD O ;End DP DY ;Patch the RT11 two sided DY handler DY2SID 3 ;DYO:, DY1: on this processor LIST 0,3,0,WP ;DYO:Processor 3 to DYO: write protect LIST 1,3,1 ~DY1: Processor 3 to DY1: no WP .WORD O ;End DY ~RT ;RT handler for Ramtek colour display .IF NDF NRT ;Following code if no Ramtek on this processor ;Patch the RT11 V3B 'null type' RT handler RT3BNL 0 ;No RT units .WORD 0 ;End RT .IFF ~Following code if Ramtek present ;Patch the RT11 V3B RT handler RT3B 1 ;RTO: present LIST 0,1,0 ;RTO: Processor 1 to RTO: LIST 0,2,0 ;RTO:Processor 2 to RTO: LIST 0,3,0 ~RTO: Processor 3 to RTO: .WORD 0 ;End RT .ENDC ;End of conditional assembly for RT ;LS ;Patch the RT1 V3B 'null type' LS handler LS3BNL 0 ;No LS units .WORD 0 ;End LS ;MU ;Patch the RT11 V4 MU message handler MU4 1 ~MUO: present .WORD 0 ;End MU CROSS RK,4,1,DY,0,WP ;RK4: Proc. 1 to DYO: with Write Protect (WP) CROSS RK,S,1,DY,1 ;RK5: Proc. 1 to DY1: no WP CROSS RK,4,2,DY,0,WP ;RK4: Proc 2 to DYO: WP CROSS RK,5,2,DY,1 ;RK5: Proc 2 to DY1: no WP CROSS RK,6,1,MU,0 ;RK6: Proc. 1 to MUO: no WP CROSS RK,6,2,MU,0 sRK6: Proc. 2 to MUD: no WP CROSS RK,6,3,MU,0 ;RK6: Proc. 3 to MUD: no WP .WORD 0 ;End of file marker END

Claims (3)

1. Claims 1. A multiple processor data handling network in which each processor has access to at least one associated peripheral device under the control of a respective handler of the operating system of that processor and has access to the peripheral device or devices associated with a second or further processors of the network through a data transmission link such that, on receipt by the operating system of any one of the processors of a request for access to a peripheral device which is not available for direct access by said one processor through its own operating system, that processor via the data transmission link can activate and assume control of the handler of another processor to which the given peripheral device is available.
2. 2. A network as claimed in Claim 1 in which said one processor is arranged to output an identification code identifying the peripheral device it requires and the identification code is routed by the data transmission link to all of the data inputs of all of the other processors of the network, each processor being arranged to recognise identification codes applicable to the peripheral device or devices to which it has access via its own handler(s) and, on such recognition, output an acknowledgement code via the data link whereby a master-slave relationship is set up between said one processor and any processor acknowledging the identification code thus enabling the master processor to output data via the data link directly to the corresponding handler of the slave processor and hence to the given peripheral device.
3. 3. A multiple processor data handling network substantially as hereinbefore described with reference to, and as shown in, the accompanying drawings.