GB2293675A - Process allocation in a data processing system - Google Patents

Description

1 DATA PRWESSING SYSTEM AND OPERATING 'yY 2293675 This invention relates

to data processing systems and to operating systems therefor. In particular, the invention relates to operating systems for computers and computer networks.

In order to function, a computer or computer system must comprise hardware, such as one or more processors, input/output means, memory and various peripheral devices, and software in the form of both operating programs to cause the hardware to perform in a certain manner and higher level programs which instruct the operating programs to perform operations. Many operating systems have been designed in attempts to obtain the best possible performance from the various processors available. Many of these operating systems are unique to one particular processor. Furthermore, they may only support one or a small number of processing languages.

The present invention arose in an attempt to design an improved computer and computer operating system involving a plurality of processors capable of operating in parallel and comprising an improved means of allocating processes to be performed to individual processors within the system in the most efficaceous manner.

In accordance with this invention, a data processing system is provided comprising a plurality of processors interconnected as nodes in a network and wherein the network is arranged to perform a process of process allocation in which the processor at any given node in the network, upon receiving instructions to perform a process, decides whether it, or a data processor at one of the neighbouring nodes, is better able, at that time, to perform the process, and in accordance with that decision either performs the process itself or passes the instruction 2 is to perform the process to that neighbouring processor.

in one embodiment the data processor at the first node may send a message to the data processor at each adjacent node indicative of the processing space required to execute the process, the processor at the first node also determining itself whether it has sufficient remaining space, the processor at each adjacent node being arranged to reply to the processor at the first node with information indicative of whether the space is available, and wherein the processor at the first node compares the replies with its own determination and either passes the process on to whichever of the neighbouring processors has the most space available, or takes the process itself if it has the most space available.

Alternatively, the processor with the highest "power rating" is selected, the power rating being the effective operations per second rating of the processor at any given node divided by the number of processes running at that processor and multiplied by a function of the offichip communication speed available to the processor in question. Other methods and schemes of making the decision may be used.

Other aspects and features of the invention will be described with reference to the accompanying drawings, in which:

Figure 1 shows schematically the program organisation of a computer system; Figure 2 shows the hierarchy of the organisation of Figure Figure 3 shows the inter-relationship between a number of associated microprocessors dur-ing setting up of the computer system; gure: shows the same relazionship a- a later stage during rrocessing; shows a schema::c flow char-,:)rocess allocamion.

The following descr,-ptiolr is of a computing nezworic. having a plurality of processors, which may be arranged either in the same vicinity, perhaps on,,he same wafer or chip, or sDread out in a network linked by hard wiring, ortical fibres, longer distance telecommunication 11.4nes, or by any other means. The system described is sufficiently flexible that any o""' these configurations and others besides, are appropriate. The system may alternatively include just one proce.s sor. The processor or processors are arranged to perform operations, programs and processes under the control of an operating system. The operating system enables programs to be written for an imaginary processor, known as a virtual processor, which has its own predefined language. This virtual processor enables any type of target processor to be used, or combinations of different types of processor, since,ne program code written for the virtual processor is only translated at load time into the native code of each Drocessor. Thus, executable ffiles can be transferred to any supported processor without modification or recomrilation. -Typical processors which are suitable for the system -nclude the inmos TBOO Transputer, Motorfoia 68OXO, Intel 80366/80486, TM534C40 Archimedes ARM and SUN SPARC. Other processors are of course suitable. The operating system is adapted for parallel processing such that more -.han one oreration may be conducted simultaneousiy, as orposed to conventional computing systems whic-n must pipeiine data and operation so C' that onlly one operation can be performed at any one t capabilities are ime. Multi-tasking and multi-user also included.

The system is data flow-driven and essenzJally involves a plurality of code segments or llools, which are bound into a complete executable task only at the time of loading. Thus, each of these tools can be very short and, in themselves, almost trivial in their simplicity. For comparison, it should be noted that traditional computing binds routines such as libraries, functions, and so on just he comiDile stage in a process known as after t linkinz. The resulting file is a large, bulky, comDlete selfcontained executable image requiring very little modification at load time. The file is not portable across processors and cannot easily adapt to changing components such as systems with small memory capacities. Furthermore, the component parts thereof cannot be reused for other tasks or indeed changed at all. The small components used in ,he Dresent invention, which are only brought the last minute (a zogether to form an operation at.

just in. time process) are of course completely poriable and may alsb be shared between two or more processes at the same time, even though the Drocesses are Derforming different jobs. Some tools are desiRned for a Darticular application and others are designed without any particular aDDlication in mind. With the late binding process, program components can also be during execution. Thus, large arDlications having a -y can in fact run (nominally) large capacit,n a small memory capacity system and the application can choose to have available in memory only that Darticular code segment or segments required at any r) ime, as is described below.

one t.

Data in the system is passed in the c:O messa-ces between code comuonents. A code comDonent which is capable of receiving and sending messages is known as a process and consists of a collection of tools and the binding logic for these and the data being processed. The system is lustrazed schematically in Figure 1 in which there is shown a central kernal of program code. The kernal is one 'block' and is the basic 0Derating system which is used by all the processors in the network. Typically, it is Of 8 to 16 kilobytes. Schemamically illustrated outside the kernal are a plurality of tool objects 2, any collection which can form a process. A third level of program code is given by the tools 3. A typical process is shown by the arrows in the figure. Thus, a process which we shall call P1 comprises the kernal code 1 plus two tool objects M1 and M2. Each of these tool objects, which may be of only a few hundred bytes long, can utilise one or more of the tools 3. In this case, tool object M1 utilises tools T1, 'T2 and T3 and tool object M2 utilises T3 (again), T4, T5 and T6. It is thus seen from the figure that a relatively complex process or program can be performed by using a -0 the relatively small segments, which are ulurality o.L broujzht toRether onlv when necessary. More than one Drocess can be Derformed simultaneously by placing each process upon a different processor. The actual 3 0 placement oil processes occurs by an automatic method outlined below, which method is transiDarent to the user, and indeed, to the system as a whole. Thus, optimum load balancing and communications efficiency is ensured. As a resul - 'of this, a number of processes that communicate can be automatically run C, n narallel.

The three fundamental component objects of +,he svstem are shown in Figure 27. These comrrise data objects, -.ool objects (tools) and process objects. A process object acts as a harness to call var.,ous tool objects. A process essentially directs the logic flow of an activity and directs tool objects to act on data. Thus, a process object is az -,.he tcD c..Ie hierarchical structure shown in Figure 2. Al. tool object corresponds to a traditional functional call or sub-routine. It can only be used by reference and must be activated by something else such as a process object. This is similar to the manner in which a function in C language is called by a main body of code, the imDortant distinction being that in the rresent system each code segment, ie tool, is completely independent. Finally, a data object correSDonds to a data file. A data file may contain information about itself and about how it can be Drocessed. his information can comprise, for example, information that voints to the tool used to maniDulate the data structure and local data -1e. A process can have a publicly relating to this f defined input and output, such as an ASCII data stream. The process can thus be used by third party processes, -i-- ncz only by the author. A process that is not publicly available wi'l have a private input and output structure and thus is on-,y -free for use by the author o:f a particular program, unless details of 3 0 the input/ouiput interf-ace are made Dublicly available. One er more processes may combine to form an aDDlication which is a complete job of work. It should be noted that an a=lication can run on two or more processors.

As descr,-bed above, aiDulications can be - 7 2--, imul-.i-zasked and/or parallel processed. Processes can activate other, cl-il-l, -crocesses which can:hemselves acz-.vaze on,-]-,-; (grandch-J Ild) rrocesses and so on. These Drocesses are distributed throueh the available network of processors dynamically, and without the application or 'the programmer knowing the actual distribution. Communication between rrocesses 'here are no s based on a parenz-child hierarchy. T "master" nodes or processors as such and any arbitrary topology of any number of processors may be used. Figure 5 shows one possible algorithm ú for distributing processes between different processors in the network.

When a parent process wishes to co-process with a child process the message is firstly passed to a first processor, and in Darticular to the kernel mrocess on that Drocessor. This Drocess handles messages to and from the processor and acts as a process control/message switcher. The kernel of the first processor, designated "A" then calculates the "iDower rating" of the processor. The Dower rating is essentially a measure of the capacity or sDace within that rrocessor to Derform that particular process. The Dower rating may be defined as being the effective operations Der second razing c."' the Drocessor divided by the number of processes f function c.

running on that processor multiplied by a. che off chir communicazions SDeed available to it. Other methods of determining a Dower rating may of course be used. For -nstance, a message to perform rarticular rrocess will be acco=Danied by the number ---0 bytes recuired by the process. Thus the Dower razing may comprise deTermining whether that number bvces are available within the nrocessors local memory. This memory may be an on-chip memory for a a S - 6 processor such as a transDuler, or may be off-Chip. The local kernel then instructs the kernel of every neighbouring processor in the network (remembering that by neighbouring is meant tODO1ORiCallY neighbouring and that physically the processors may be a large distance apart) to calculate their own Dower ratings. Each of the neighbouring processors then sends a message back to the parent processor A indicative of the respect-live Dower rating. The mail guardian of A then compares all of the Dower ratings and decides if its own Dower rating is greater " than or equal to that of its neighbours. If so then the maill guardian of A decides to accept the process itself. It does this by instructing its own dynamic binder and translator (see below) to instal the child, then sends a message to the instructing processor informing it of the unique mail box address on the receiving processor. If the power rating of processor A is not greater than or equal to that of 0 its neighbours then whichever -Drocessor has the greatest Dower rating is chosen to acceDt the process. If all power ratings are equal then processor A will accept the process. Alternatively, a neighbouring may be selected arbitratily. 7-f the -hen Drocess is allocated to another Drocessor t processor A sends a message to that processor saying take X Bytes, 2rocess name, Darent mail box no.".

Having found a processor to take the child process, the urocess allocation dynamics could stop 0 and the process could be performed. However, it is more usual to reDeat the same allocation seauence C from the new rrocessor, ie, in the flow chart shown in Figure 15, the new processor chosen, processor -E becomes processor A and the cycle starts again from,he step of reauesting the neighbours to calculate - a - their power ratings. '-"hus, the search for a local processor having the minimumcurrent activity and thus greatest capacity to perform a process automatically tends to flood out from a centre Doint which is the originating master parent. This substantially guarantees load balancing between the network of Drocessors and local communications between tightly bound processes. Furthermore, it is seen from the above that no master node is reauired and in any network any one processor will usually have no more than one Drocess more than any neighbour to perform at any time, if identical types. Alternatively, in some.embodiments the user can, if desired, select which processor or type oil processor can perform a process. For instance, if the network contains two types of processor, one of these types may be better adapted to perform a particular process, dependent upon memory capacity, for example. The user can then specify that this process is to be performed by a particular type of processor. It is "hat.1 also seen t he rrocess, and therefore the programmer, has no requirement to know exactly where it is in the network. A message can carry either data or code between processors, allowing messages to be in the form c--!- runnable code.

In an alternative embodiment, the processors may continually pass information relating to their "Dower rating" between each other. This may be passed as embedded information in messages passed during the normal course of communication or, during periods where no,messaaes are being passed between processors, a specific exchange of power rating iformation only may occur, thus using unused n: communication time most efficiently. Each processor can then be provided with a look-uD table, for 1 - examDle, which gives the status of its immediate neighbouring processors and its own immediate status.

The power ratinR information may, for examDle, be passed in the form of one or a few bytes at the e nd or begining of each ordinary message passed between processors. in this embodiment, when receiving a request to perform a process, a processor can immediately determine whether or not to take the process itself or to pass it to a neighbouring processor, and will know which one. Having determined to Dass an a reauest to a neighbouring processor, the request is sent and the receiving processor then starts the decision process again until such a time as aj processor determines that is best adapted to perform the 'orocess itself.

A mrocess can be in one of five distinct states, these are 2. 3. 4. 5.

actively processing waiting for input withdrawing inactive asleeD.

States 1 and 2 require no comment. State 3 occurs when a process has received a command to withdraw. In this state a process performs any activity which is necessary to become inactive. This can include, 0 for examDle, processing urgent mail, sending withdraw 3 0 messages to all of its child processes, if any and generally preparing for a convenient state in which can go inactive. If the process forms the top level of an aDrlication then it will often save its exact current state as a message in a disk file.

State 4 represents a Drocess that is effectively z this would mean erminaT,ed. In zrad-,zional systems, that the process in memory would cease to exist and s memory space would be cleared fc- subsequenz use. In the system according zo the present invention, Js not however, the Drocess is marked as inactive but. removed unless and until its memory space is actually required. Thus, iff another process in the same local,=rocessor references an inactive rroess in state 4 iz can immediately go to state 2. Stame 5 is that state of a process when -Ai.4L, is in rermaneni store such as on disk or other storage medium. When a rrocess.,,is inactive in state 4 and its memory space is required another -process, then that process goes from state 4 to state IS, le is stored on disk and removed from the local processors memory. When a process which is in state 5 is required for a particular local processor, that process is loaded from 'permanent store. Mail may then be available for the processor which mail is take4Kfrom three sources either from the process' state on disk, or from the process' own header, ie information forming part of the process, or mail from the parent process which d causethe process to be loaded in the first place.

This can cause the process to transit from state JI -.c state 2 and then to state 1.

The -,,er= s;,-.-.oduced above. '"his _Js a device containinR a collection of data objeczs "f-les" s-.orec cn a pnysicall storage medium. C5 As described, all process<are automatJcal".y F-iven mailbox facilities and can read and send mail,c any other process having a known mailing address.

-41 This process could be, for example, a child process, the parent ----0 the process, any named resource, for examrle a disk c- a d-srla,,, any inactive process whose full sTorage address is known or any 1 A -12 other process having k known mailbox address. If an active trocess sends mail to an inactive process the mail may cause the inactive process to be executed as a child rrocess or the mail may be stored until the target process is awake.

A messaae Dassed between two active processes may take the following structure:

r 1 bits 32 3 2 3 _ 2 32 64 64 64 De s c r 4. ot i on Message length in bytes Message Type Mask - type of message, eg code, debugging information, error data ffset - points Mess-age data ol o start of message and therefore allows for the fact that the DTM (see below) is not a fixed length Next Destination Pointer (NDP) signifies the address to which a reply should be directed Originator Mailbox Destination Target Mailbox (DTM) list of process ID's 2nd DTM (more DTM's) (xxX) message data The message length is a byte count of the L, en-L,.4'.-e len-ath of a message.

T If the Next Destination Pointer points to a Destination Target Mailbox of "0" then no reply is reaul-red or exDected. The array cl- onward - I destination mai--,boxes for messages does not imply that a rariicular message is to be forwarded. The existence cf a val-id DTM iin the array signifies that a reply -:o a message should be forwarded to that process. a simple case off a message requiring no reply the DTM array will contain three values, the originator process mailbox, the target process mailbox, then 0. Attempting to send a message to the target ID 0 causes the message to be routed to the system mail manager. A message requiring a reply to the sender will have a DTM array consis"Zing 0-f,.'-"our values: originator mailbox, destination mailbox, originators mailbox, 0.

A pipe line of processes handling a stream of data will receive a DTM array which has (number o. processing pipe) + two elements, including the originators mailbox, plus the final destination as one of the processes in the pipe.

Porked' pipe schemes are possible but require that a process actively creates the fork, with another process possible actively joining the fork later. Simple linear DiDes need only reusable tool objects that oDerate in a similar fashion to Unix f.-lters (as known to those skilled in the art) but can run in parallel and can be nersisTent in the network.

Forked and lo-inted messarzing is automatically nandled when programming using the shell with simDle inDut-outDut filter tools.

Once in the memory space c--17' a destination Drocess the message structure has two further elements added before the message length:

bits Descri'Dtion 72 'Forward link pointer 32 32 3 2 e -c c 14 Backward link Dointer Message length in bytes Message Type Mask The forward and backward link roint to other messages, if any, that make up the linked list of messages for a process's incoming mailbox.

Mail is read by a processor in two stages, first the size of the message, then the rest of the message into a buffer allocated dynamically for the message. This mechanism allows for a messag& to be redirected around a failed node or a kernel which is, for some reason, incap. able of receiving a message.

Messages ma y be allowed to be distributed to more than one destination, by means of a mail group distributor. Any process which knows that it belongs to a group of processes can send a message to a mail group distributor declaring its group membershiD. Alternatively, a process can send a message to the mail group distributor which defines he mail all its member processes. Once informed, 4. group distributor informs all member processes of the mailbox ID which is to be used for that group. Mail which is to be distributed to all members of the grour is sent to the group mailbox and copies are sent to all member.except the originator. A single nrocess may belong to more than one mail group, and sub-groupS May I provided. Private messages can also be sent between processes in a group without all other rrocesses being aware.

The following types of tool may be used; Dermanent tools form the core of the operating sys-tem. 'I"hey are activated by the boot-up sequence and canno- then be disabled. "Every processor always -5 3 - ll 5 nas a copy c-f each De=anent toci available Semi-Dermanen. tools are activated for every processor by the 'coc."e-rocess. The user can -ncose wh-Jc" semi-Dermanen: tools can be activated.

Once activated they cannot be deactivated.

--'':)rary:oo-,S are used as recured cm a -hey named library of tools. Once activated, t :-ema-ln cached in 'the memory of any processor that has rur. an aun",-J--a-ti.on that references them, an-..l memory constraints recuire their deactivation.

ADDlication tools are either virtual or -ive non-virtual. Virtual ones are not necessarily act when an application is running, but are activated as 7ecuired when a mrocess atcemDzs zc reference them.

1 c: Vhen not running, the virtual tool remains cached un-iess the memory space is otherwise reouired. Thus, automatic 'overlay' is available for tools in large 0it into available memory.

aDDlications that cannot A Non-virtual tools are loaded with an aDDlication and in active Dlace before it executes. Thus, they are always available, and in memory during execution.

Each processor, or group of processors, in -he he network includes a uermanent tool known as 411 dynamic binder and translator "DBAT". DBAT is written in the native code of the processor, and thus a specific version c--" DEAT 's required 'or eac,, different surDorted rrocessor. E.EAT is caDable of converting the v,_-tua_ ziocessing cone into the 255 - c; native cone c: tne processor.

Each DBAT uses a list of tools. the list s a permanent and external tool list (PET-L) which c=tains information about all uermanenz and semi permanent tools (this!is-,, is identical for every rode) Jp and all external tools suc- as libraries wnich are currenily re,-'erence,-J by -he node, or j 1 16.

previously referenced and still active, or inactive yet still available, for each individual node. On receiving a command to execute a message, the object is read into the local memory area of the process. By the term processor is also meant more than one processor which is connected in a network with one DBAT. A pass is made through the object. In that pass, DBAT adds tools to the PETL.

External tools are added to the PETL in the following way; if the tool is already in the PETL, it is accepted as available, or, if the tool does not exist in the PETL it is read in, and linked into the Est of available tools. if this newly installed tool contains other tool references, DBAT deals with these recursively in the same way.

DBAT continues until all the external tools are available.

DBAT 'translates' the VP code of the process and newly installed tools to the target processor, inserting and correcting pointer information to tools inside the code. The unresolved virtual tool references are converted to a TRAP to the virtual tool handler inside DBAT, With a parameter pointing to the full pathriame of the tool. On completion, DBAT allows the process to execute.

As each external tool is referenced by an incoming process, it has its usage flag incremented so that the tool has a value for the number of processes currently using it. As each process activates, the usage flag is decremented. When no process is using a tool, the tool has a usage flag value of zero, and can be de-activated by removal from the PETL and its memory released. This will only happen if memory space garbage collection -------------------------------------- - - - 17 - r, occurs, allowing the system to cache tools. Semi permanent and Dermanenz tools are installed by DBAT at boot up with an initial usage value of i, thus ensuring that they cannot be de-activated. Virtual tools are called by a process while running. A virtual tool is referenced with a pointer to the tool's path and name, plus the tool's normal parameters.

"'he virtual tool handler in DBAT checks the PETL to see if the tool is already available.

T -P so the too! is used as for a normal external - _17 tool. If it is absent DBAT activates the tool (the same rrocess as for any external tool activated during a process start up) and then passes on the tool reference. This is entirely transparent with the exception that memory constraints may cause a fault if even garbage collection fails to find enough memory for the incoming tool. Virtual memory techiques can be used to guarantee this memory.

Figures 7 and 4 show, schematically, a system in operation. Three processors (or processor arrays) 4 are shown, schematically 'linked' to a central 'virtual' processor VP. it is assumed that each Drocessor has a total memory, either on or off chi-. At. boot up, each processor takes in DBAT and all the other rermanent (Pi... 1n) and semi permanent. tools (SP,... SP.). This state is shown in Figure All processors contain the same group of permanent and semi permanent tools.

Figure 4 shows a later state. One rrocessor has been instructed to Derform a process which uses 11-41-rary tools Ij,,, L I-),.

and L4.

It therefore has read these in. In turn, this tual or other i7rocessor may read in various vir, -1 1 0 0 1 1 r_ tools as required to execute a particular process. Another processor has read in tools L 5, L6, L7 and Lp. The final Drocessor is not, presently, performing any process. Two or more processors may, of course, use the same library function by reading a copy of it into local memory. Once a process has ended, the library -tools remain cached in the resDective local memories until needed a-gain, or until garbaae collection. Of course, several Drocesses may be runsimultaneously on any nrocessor network as described above.

As well as handling the translation of VP code to native processor code, DBAT may, in some embodiments, recognise -native rrocessor coding. Using native coding prevents portability of code but 's acceDtable as a strategy for hardware specific 'tools (commonly drivers).

It should be noted that a process or tool may be coded either in VP code or native code, and mixed source objects may be used together. However VP and native code cannot usually be mixed within a single object. A utility based in DBAT will accept VP code input and output native code for later running. This allows time critical application to be fully portable in VP 'source', but 'compiled' completely for a target system.

T n order to help prevent unconstrained -he copying of applications, applications may retain use of nature coded objects ability keeping the original VP coding in house for the creation of different Droducts based on sDecif'ic iDrocessors. However, use of this feature prevents applications C - om running on parallel systems with mixed processor .ypes -z C, 1.0 an exzernally referenced tool is not available then an error may be.displayed. under the action of DBAT with the rnown details of the missing too.. The user can then decide whether to temDorar,--',,, replace the rmissing tool with another.'tu.1i,e another. Tool one or to permanently subst.

loss may occur by a missing or broken access route/path or, for examule, where a removable medium such as a floDD - -L - y disk is currently not accessible. Objects can be moved on and off a network, but -.his may often involve the removal of a whole aDrlicazion, all its dependent processes etc.

The virtual -Drocessor described abo_ve is an imaginary processor used to construct portable .able" code. As.described above, the cui;Dut c,-" Pc e x e cut VP coml:)atible assemblers and comDilers does not require linking due to the extremely late binding system which uses DBAT.

An 'executable' in VP code is processed by DBAT to its host target processor at load time before control is Dassed to the cone. 'The VP has a 16 by 32 bit register set with an assumed 72 bit linear address space, but not limited to 16. Registers RO tc R15 arelcompletely general- purpose. Registers such as an IP, segment DoinTers, flags, etc are assumed, thatil is, they are implemented as necessary by the target processor. VP code is designed to be extremely s,riD-ie zo 'translatel to a modern zarRez 0 -nerating philosophy. Other rrocessor. reRardless c- word sized urocessors than.72 bit ones can be handled -O easily. VP register set usage is not removed in the f4nal targeT execuTablee code. The register set is o---en imulemenTed in memc7,, (called ghost registers) f I.

00 reuired to,k with the target register set being used as implement the VP operation set on the memory - l sters. This nseudo -nzerr)reta-.Lon of VP ez- - 20 coding by a native processor may have a slight sT)eed disadvantage for some rrocessors, but many benefits overall. Processors with cached or fast memory (such as the transputer) can actually show a Derfcrmance increase, particularly where the native register set is very small, as in the transputer. Task switching times are extremely fast using this scheme since the state of the native lDrocessor can be 4anored, with the excertion of a memory write to save the T)osition of an outgoing task's register set, and memory read to restore the register position of the 4 incoming task. The transputer architecture makes Z even this unnecessary. Some embodiments may have a " DBAT-that does not convert VP simple version of coding to native coding. These use VP macros that are complied by a target processor macro assembler into target executables. However certain constructs, such as references to tools, objects, etc, are retained for processing and fixup by DBAT. Industry standard target macro assemblers are perfectly suitable for this conversion.

The efficiency of code uWimately run on a target processor is dependent on The two stages of compilation and assembly by the VP comi)iler and DBAIT I a comriler -to reduce respectively. The ability o..he VP outiout To it's most ef,-- ient form is not hami)ered, but obviously little or no DeeT)hole optimisaiion can Take place. DBAT performs peernole ot)timisations on the final code produced primarily by removing redundant native register/ghcst register movements that can be nroduced by some sequences of VP codes.

On transputers, VP ghost registers can result in ecual or better Derformance than.raditiona-, register use. Ghost re,ziszers are nlaced n in on-chip RAM on transputers, effectively producing a'data cache' for all processes running. Up to 48 processes can use on-chip memory ghost registers on an Inmos T800 transputer. Further processes require space in off-chip memory.

The system described may include a graphical user interface for operating using windows, mice and the like. Windows can be displaced, with respect to a display means, and operated on, or their contents operated on, by means of a mouse, keyboard, or other input means.

In relation to the systems described above with reference to the accompanying drawings, the feature or features which constitute the present invention are defined and set out in the following claims. Other aspects of those systems are protected in their own right by Application No. GB 9506109.9 ( GB-A-2 286 269), the parent of the present application, and by a second divsional application, Application No. ( GB-A- Finally and without prejudice to other Trade Marks used herein and not so acknowledged, the following are specifically acknowledged as Registered Trade Marks: INMOS TRANSPUTER MOTOROLA INTEL

Claims (10)

1. A data processing system comprising a plurality of data processors interconnected as nodes in a network and able to perform processes in parallel, wherein the network is arranged to perform a process of process allocation in which the data processor at any given node, upon receiving instrusions to perform a process, decides whether it, or a processor at one of the neighbouring nodes, is better able to perform the process, and in accordance with that decision either performs the process itself, or passes the instruction to perform the process to that neighbouring processor.
2. 2. A system as claimed in Claim 1, wherein the first-mentioned processor determines a rating of itself and ratings of its neighbouring processors for performing the process, compares the thus deteremined ratings to determine which of the processors has the highest rating, and then either allocates the process to whichever of the neighbouring processors has the highest rating, or performs the process itself if it itself has the highest rating.
3. 3. A system as claimed in Claim 2, wherein, if the first-mentioned processor and one or more of the neighbouring processors have equal highest ratings, the first-mentioned processor performs the process itself.
4. 4. A system as claimed in Claim 2 or 3, wherein the rating of each processor is determined from the number of processes currently running on that processor.
5. 5. A system as claimed in Claim 4, wherein the rating of each processor is determined from the effect ive-operations-per-second rating of that processor divided by the number of processes running at that processor multiplied by a function of the off- chip communication speed available to that processor.
6. 6. A system as claimed in Claim 2 or 3, wherein the rating of each processor is 30 determined from the available amount of local memory of that processor.
7. 7. A system as claimed in any of Claims 1 to 6, wherein the network is further arranged to repeat the process of process allocation, at least once, from the processor receiving the process in the first place, with the processor to which the task was then allocated then becoming the "first" processor.
8. 8. A system as claimed in any of Claims 1 to 7, wherein, to allocate the process to the processor at one of the neighbouring nodes, the first processor instructs the neighbouring processor with data indicative of the number of bytes required, the name of the process, and the address at which the process is currently stored.
9. 9. A system as claimed in any of Claims 1 to 8, wherein information relating to the ability of the processors at the nodes to perform processes is added to other messages passed between those processors.
10. 10. A system as claimed in any of Claims 1 to 8, wherein information relating to the 15 ability of the processors at the nodes to perform processes is passed between pairs of processors at adjacent nodes when no other information is being passed between those processors.