KR20010080958A - Concurrent processing for event-based systems - Google Patents

Abstract

According to the invention, multiple shared-memory processors 11 are inserted at the highest level of the hierarchical distributed processing system 1, and the use of the processor is maximized based on the parallel event flow identified in the system. In the first phase, a so-called non-switching category (NCC) of events is mapped to multiple processors 11 and executed in parallel. In a second aspect of the invention, the processor 11 operates in a multiprocessor pipeline, where each event reaching the pipeline is processed in a slice into a series of internal events that are executed at different stages of the pipeline. The general processing structure is obtained by what is called matrix processing. In this case, the non-switched categories are executed by different processor sets, with at least one processor set operating as a multiprocessor pipeline in which external events are processed in slices of different processor stages in the pipeline.

Description

Parallel processing of event-based systems {CONCURRENT PROCESSING FOR EVENT-BASED SYSTEMS}

From a computer point of view, many systems based on events consist of hierarchical distributed processing systems. For example, in modern telecommunications and data communications networks, each network node typically includes a processor layer that processes events from the network. In general, processors in a hierarchy communicate using message delivery, and processors at lower levels of the processor hierarchy perform simpler, lower levels of sub-task processing, and processors at higher levels of the hierarchy. Perform more complex high level task processing.

The hierarchical structure already presents some inherent parallelism, but as the number of events to be processed per unit of time increases, the higher level processor tier becomes a bottleneck to further increase performance. For example, if the processor layer is implemented in a "tree" structure, the processor at the highest level of the layer becomes the initial bottleneck.

Conventional approaches to alleviate this problem mainly rely on using higher processor clock frequencies, faster memory, and instruction pipelining.

U.S. Patent No. 5,239,539 to Uchida et al. Discloses a controller for controlling a switching network of an ATM switch by spreading the load evenly among a plurality of call processors. The main processor assigns the generated call processing to the processor either in a call generation sequence or using a channel identifier assigned to each call cell. The switching state controller collects usage information for the plurality of buffers in the switching network, and the call processor performs call processing according to the contents of the switching state controller.

Japanese Patent Summary JP 6276198 discloses a packet switch provided with a plurality of processor units, and the switching processing of the packets is performed so that the units are mutually independent.

Japanese Patent Summary JP 4100449 A discloses an ATM communication system that distributes signal cells between an ATM switch and a signaling processor array (SPA) by STM-multiplexing an ATM channel. Distributing the processing load is realized by switching signal cells using the STM according to the SPA number added to each virtual channel by a routing tag adder.

Japanese Patent Summary JP 5274279 discloses a parallel processing apparatus in the form of a hierarchical processor set in which a group of processor elements is responsible for parallel / pipeline processing.

BACKGROUND OF THE INVENTION The present invention generally relates to event-based processing systems, and more particularly to hierarchical distributed processing systems and processing methods in such processing systems.

1 is a schematic diagram of a hierarchical distributed processing system having a high level processor node in accordance with the present invention;

2 is a schematic diagram of a processing system according to a first aspect of the invention;

3 illustrates an implementation of a given processing system according to a first aspect of the invention.

4 is a schematic diagram of a simplified shared-memory multiprocessor with shared-memory software of an object-oriented design.

5A is a schematic representation of a particularly advantageous treatment system according to a second aspect of the present invention.

5B illustrates a multiprocessor pipeline in accordance with a second aspect of the present invention.

6 illustrates ensuring data matching using locking of blocks / objects.

7 illustrates detecting access conflicts using variable markings.

8A illustrates a conventional single-processor system from a layered perspective.

8B illustrates a multiprocessor system from a layered perspective.

9 is a schematic diagram of a communication system in which at least one processing system according to the present invention is implemented.

It is an object of the present invention to increase the throughput of an event based hierarchical distributed processing system. In particular, it is desirable to alleviate bottlenecks formed by high level processor nodes in hierarchical systems.

It is another object of the present invention to provide a processing system that can effectively process events based on the event flow parallel processing identified within the system and that it is desirable to operate as a high level processor node, but not necessarily.

It is a further object of the present invention to provide a processing system which can still use the concurrent processing in the event flow while still allowing reuse of current application software.

Another object of the present invention is to provide a method for effectively processing an event in a hierarchical distributed processing system.

These and other objects are met by the present invention as defined by the appended claims.

A general concept according to the present invention is to insert multiple shared-memory processors at the highest level of a hierarchical distributed processing system to maximize the use of multiple processors based on the identified parallel processing event flow within the system.

In a first aspect of the invention, the external event flow is divided into parallel categories called non-commuting categories, which are then mapped to multiple processors for parallel execution. Non-exchange categories are generally groups of events in which the order of events within a category should be maintained but no ordering conditions between categories. For example, a non-switched category can be defined by an event generated by a defined source, such as a given input port, regional processor, or hardware device connected to the system. Each non-switched category of events is assigned to one or more defined processor sets, and internal events generated by the defined processor set are fed back to the same processor set to maintain the non-switched categories assigned to the processor set.

In a second aspect of the invention, a multiprocessor operates in a multiprocessor pipeline with multiple processor stages, where each external event arriving at the pipeline is executed in a series of different pipeline stages. Processed on a slice as an internal event. In general, each pipeline stage runs on one processor, but a given processor may execute more than one pipeline stage. A particularly advantageous way of realizing a multiprocessor pipeline is to assign a software block / class cluster in shared memory software to each processor (where each event is targeted to a specific block) and then to the processor according to the assignment. Distribute the event.

The general processing structure is obtained by what is called matrix processing, where the non-switching categories are executed by different processor sets, where at least one processor set is processed in slices within different processor stages of the pipeline. It is a form of processor array that operates as a multiprocessor pipeline.

In a shared memory system, entire applications and data are accessible to all shared-memory processors in the system. Therefore, data consistency must be ensured when global data is processed by the processor.

According to the present invention, data matching can be ensured by locking global data to be used by a software task executed in response to an event, or by locking the entire software block / object in the case of an object-oriented software design. If the processing of events requires resources from more than one block, the locking approach can cause deadlocks where tasks lock each other. Thus, deadlocks can be completely avoided by detecting deadlocks and performing rollbacks to ensure progress or, optionally, seize all the blocks needed for the task before starting the task execution.

Another approach to ensure data matching is based on parallel task execution in which access conflicts between tasks are detected and the executing task in which the conflict is detected is rolled back and restarted. Collisions may be detected based on variable usage markings, or optionally based on address comparisons where read and write addresses are compared.

By marking larger areas instead of individual data, coarse-grained collision checking is realized.

The solution according to the invention actually increases the processing capacity of the processing system and, in the case of hierarchical processing systems, the high level bottleneck is effectively alleviated.

By using a shared-memory multiprocessor and providing a means of ensuring proper data matching, application software already present in a single-processor system can be reused. In many cases, millions of lines of code may already be used in a single-processor system, such as a single-processor node at the highest level of a hierarchical processing system. When implementing multiple processors using standard off-the-shelf multiprocessors, the application software is automatically converted and, if possible, multiple virtual machine / operating systems in the system. By changing to support the processor, all current application software can be reused. On the other hand, if the multiprocessor is implemented with special hardware of proprietary design, the application software can be moved directly to the multiprocessor environment. Either way, this saves valuable time and reduces programming costs compared to designing application software with scratch.

The present invention provides the following advantages:

Increasing treatment capacity;

-Bottleneck mitigation;

In particular, object-oriented design allows reuse of existing application software.

Advantages other than those provided by the present invention will become apparent upon reading the following detailed description of embodiments of the present invention.

The invention and its objects and advantages are best understood by reference to the following detailed description taken in conjunction with the accompanying drawings.

Throughout the drawings, the same reference characters are used for corresponding or similar elements.

1 is a schematic diagram of a hierarchical distributed processing system having a high level processor node according to the present invention. The hierarchical distributed processing system 1 has a conventional tree structure with multiple processor nodes distributed across multiple system hierarchical levels. For example, hierarchical processing systems may be found in telecommunication nodes and routers. Inherently, high level processor nodes, and especially the top processor nodes, become a bottleneck as the number of events to be processed by the processing system increases.

An effective way to mitigate the bottleneck in accordance with the present invention involves using multiple shared-memory processors 11 at the highest level of the hierarchy. In FIG. 1, multiple processors are shown implemented at the top node 10. The multiple shared-memory processor 11 is preferably implemented in the form of a standard microprocessor based on a multiprocessor system. All the processors 11 share a common memory called the shared memory 12. In general, an external asynchronous event tied to a high level processor node 10 first arrives at an input / output (I / O) unit 13, from which it is a mapper or distributor. 14). The mapper 14 processes the events by mapping / distributing the events to the processor 11.

Based on the event flow parallel processing identified in the hierarchical processing system 1, the external event flow to the processor node 10 is referred to as a number of parallel processing categories (hereinafter referred to as non-commuting categories (NCCs). The mapper 14 allows each NCC to be assigned to a defined set of one or more processors 11, thereby enabling parallel processing and optimal use of multiple processors. It may be implemented in the above processor 11, the processor is preferably provided to the next mapper.

A non-exchange category is a group of events in which the order of events must be maintained within the category but without any ordering conditions in handling events from different categories. A general condition for systems where information flow is managed by a protocol is that certain related events must be processed in the order in which they are received. This is what the system does not change, no matter how it is implemented. The identification of the appropriate NCC and the parallel processing of the NCC ensure that the unique parallel processing is used in the event flow while the ordering conditions raised by the given system protocol are met.

If an external event can be processed or executed in a "slice" as a series of events, selective or another parallel execution is possible by operating one or more sets of processors in a multiprocessor pipeline. Thus, each external event arriving at the multiprocessor pipeline is processed in a slice running at different processor stages of the multiprocessor pipeline.

As a result, the general processing structure is obtained by so-called matrix processing in which the NCCs are executed by different processor sets and at least one processor set operates in a multiprocessor pipeline. It should be noted that any of the elements of the logical "matrix" of the processor shown in FIG. 1 may be empty. Reducing the logical matrix of the processor shown in FIG. 1 to one row of processors provides pure NCC processing, while reducing the matrix to one column of processors provides pure event-level pipeline processing.

Calculations for an event based system are generally modeled as a state machine where input events from the outside world can change the state of the system, resulting in output events. If each non-switched category / pipeline stage can be handled by an independent / disjoint state, there is no data sharing between the various state machines. However, given that a global resource, represented by a global state or variable, exists, operations in a given global state are usually performed at a time, with only one processor executing a portion of the system state machine accessing the given global state. Atomic ". Due to the NCC / pipeline based implementation, there is no need for so-called sequence-dependency checking.

For a better understanding, consider the following example. Assume that a given set of global variables is responsible for allocating resources such as free channels to other communication nodes. Next, for two asynchronous operations of different NCCs, the order in which they request the empty channels is not a problem-while the first request gets the first channel that meets the selection criteria, while the second request meets the criteria. Then get the available channel. The important point is that while no channel selection is in progress for one task, the other task should not interfere. Access to global variables in charge of channel assignments should be "atomic" (even in certain cases, evenly parallelizing channel surveys).

Another example involves two tasks of different NCCs that need to increment the counter. It doesn't matter which task first increments the counter, but while one of the tasks acts on the counter variable and increments it (reads its current value and adds one to the current value), it doesn't interfere. Should not.

In a shared-memory system, the entire application program space and data in shared memory 912 can be accessed by all processors. Thus, there is a need to ensure data matching when a processor needs to handle global variables common to all processors or at least one or more processors. This is done by data matching means schematically indicated by reference numeral 15 in FIG. 1.

Hereinafter, NCC processing as the first aspect of the present invention, event-level pipeline processing as the second aspect of the present invention, and processing and means for ensuring data matching will be described.

NCC processing

2 is a schematic diagram of an event-driven processing system according to the first aspect of the present invention. The processing system comprises a plurality of shared-memory processors (P1 to P4), shared memory 12, I / O-units 13, distributors 14, data matching means 15, and a number of independent parallel events. And a cue 16.

The I / O-unit 13 receives an input external event and outputs an output event. The distributor 14 divides the input event into a non-switched category (NCC) to separate each NCC into an independent event queue 16. To the specified queue. Each event queue is connected to its own processor, and each processor sequentially fetches or receives events from the associated event queue and processes them. If the events have different priority levels, this should be considered so that the processor processes the events in order of priority.

By way of example, a hierarchical processing system having a central high level processor node and a plurality of low-level processors, called so-called regional processors, where each regional processor in turn services multiple hardware devices. Let's consider. In the above system, events occurring from hardware devices and events coming from the area processor providing a service to a device group are conditions that are protected by processing at a higher level (a higher level of error raised by an ordering condition defined by a predetermined protocol). Conditions are excluded). Thus, events from certain device / area processors form a non-switching category. To maintain a non-switched category, each device / area processor must always supply its own event to the same processor.

For example, in a telecommunications application, a sequence of numbers received from a user, or a sequence of ISDN user part messages received at a trunk device must be processed in the order received, but received at two independent trunk devices. The sequence of s may be processed in any order as long as sequencing for the individual trunk devices is maintained.

In FIG. 2, events from a defined source S1, such as a given hardware device or input port, are mapped to a defined processor P1, and from another defined source S2, such as a given area processor. It can be seen that the event is mapped to another processor P3. Since the number of sources usually far exceeds the number of shared-memory processors, each processor is typically assigned to multiple sources. For common telecommunication / data communication applications, there may be 1024 area processors communicating with a single central processor node. Mapping area processors to multiple shared-memory processors within the central node in a load balancing manner means that each shared-memory processor gets approximately 256 area processors (four processors in the central node, all area processors have the same load). Is assumed to be generated). In practice, however, it may be beneficial to map hardware devices such as signaling devices, subscriber stations, etc., to a central node processor to have much more granularity. This generally makes it easier to achieve load balancing. Each area processor in a telecommunications network controls hundreds of hardware devices. So, instead of mapping more than 10,000 hardware devices to a single processor (which of course handles the load in a time-sharing manner), the solution according to the present invention is to map the hardware devices to multiple shared-memory processors in the central node, thereby providing a centralized solution. Mitigates bottlenecks in the node.

Systems such as Telefonaktiebolaget LM Ericsson's AXE Digital Switching System, which handles external or so-called internal events in slices connected by processor-to-processor (CP-to-CP) signals, are addressed by protocols. In addition to that, raise your own sequencing conditions. The CP-to-CP signals for the NCC must be processed in the order in which they were created (if not, they are replaced with higher priority signals generated by the last slice during execution). Such additional sequencing conditions are handled by the same processor as the processor on which each CP-to-CP signal (internal event) is generated, as indicated by the dashed line from processor to event queue in FIG. 2. If it is satisfied. Thus, internal events can be maintained in the same NCC by having them processed in the same order in which they were created as they were fed back to the same processor or set of processors that created them.

Usually, the representation of the event recognized by the processing system is a signal message. In general, each signal message has a header and a signal body. The signal portion contains information necessary for the execution of the software task. For example, the signal portion explicitly or implicitly contains the necessary input operands as well as pointers to software code / data in shared memory. In this respect, the event signal is standalone, which completely defines the corresponding task. Thus, processors P1 to P4 independently retrieve and process events to execute corresponding software tasks or tasks in parallel. Software tasks are also referred to as tasks, and the terms task and task are used interchangeably throughout this invention. During parallel task execution, the processor needs to process global data in shared memory. In order to avoid data inconsistency in which multiple processors access and process the same global data (during the lifetime of the task), the data matching means 15 must ensure that data matching is always guaranteed. The present invention utilizes two basic procedures to ensure data matching when global data is processed by a processor while executing tasks in parallel.

Locking: Each processor usually comprises means for forming a data matching means 15 portion to lock global data to be used by the corresponding task before starting the task execution. In this way, only processors that have locked global data can access it. The locked data is preferably released when the task finishes executing. This approach means that if global data is locked by a processor and another processor wishes to access the same data as above, another processor must wait until the locked data is released. In general, locking refers to a time wait (waiting / stall on a locked global state) that limits the amount of parallelism to some extent (of course, concurrent operations in different global states are allowed at the same time).

Collision detection and roll-back: Software tasks are executed in parallel, collisions are detected, and one or more executed tasks for which collisions are detected are rolled back and restarted. Collision detection is generally accomplished by a marker method or a bungee comparison method. In the marker method, each processor includes means for marking variable usage of shared memory, and then variable access conflicts are detected based on the marking. Collision detection generally has a penalty for rollback (which results in wasted processing).

Which approach you choose depends on your application and should be chosen on a case-to-case basis. In simple experience, locking based on data matching is more suitable for data systems, and collision detection is more beneficial for telecommunications and data communication systems. For some applications, it may be beneficial to use a combination of locking and collision detection.

The locking and collision detection as a means to ensure data matching are then described in more detail.

Fig. 3 shows the concrete implementation of the processing system according to the first aspect of the present invention. In this implementation, the processors P1 to P4 are symmetric multiprocessors SMP, with each processor having its own local cache C1 to C4, and the event queue is a dedicated memory list, preferably a concatenation. It is allocated to shared memory 12 as risk (EQ1 to EQ4).

As already mentioned, each event signal generally has a header and a signal portion. In this case, the header includes an (implicit or explicit) NCC tag that indicates the NCC to which the corresponding event belongs. The distributor 14 distributes the input event to one of the event queues EQ1 to EQ4 based on the NCC tag included in the event signal. For example, the NCC tag may be a representation of the source where the event occurs, such as an input port, an area processor, or a hardware device. Assume that an event received by the I / O-unit 13 comes from a given hardware device, which appears in a tag included in the event signal. Next, the distributor 14 calculates a tag of the event, so that the distributor 14 may define a tag among the event queues EQ1 to EQ4 allocated to the shared-memory based on a pre-stored event-dispatch table or a corresponding one. To distribute the event. Each of the processors P1 to P4 draws events from their respective dedicated event queues in the shared memory 12 via the local cache, sequentially processing and terminating the events. The event-dispatch table may be modified from time to time to adjust for long term imbalances at the traffic source.

Of course, the invention is not limited to symmetric multiprocessors with local caches. Other examples of shared-memory systems include shared-memory without a cache, shared memory with a common cache, and shared memory with a mixed cache.

Example for Object-Oriented Design

4 is a schematic diagram of a simple shared-memory multiprocessor system with shared-memory software of an object-oriented design. The software in shared memory 12 has an object-oriented design and consists of a block (B1 to Bn) or a set of classes. Each block / object is responsible for performing a given function. Typically, each block / object is divided into two main sectors: a program sector in which code is stored and a data sector in which data is stored. Code in the program sector of a block only acts on that data by accessing data belonging to the same block. Next, the data sector is also composed of two sectors, a first sector of "global" data including a plurality of global variables (GV1 to GVn), and a first sector of "private" data such as a record (RV1 to RVn). Preferably separated into two sectors. Each record typically contains a number of record variables RV1 to RVn as shown for record Rx. Each transaction is commonly associated with a record in a block, while global data in the block is shared by multiple transactions.

In general, signal input to a block initiates data processing within the block. Upon receiving an external or internal event, each processor executes the code in the block indicated by the event signal to act on the global and record variables of the block, thereby executing a software task. Execution of the software task is shown in FIG. 4 by wavy lines in each processor P1 through P4.

In the example of FIG. 4, the first processor P1 executes code in software block B88. A number of instructions (of which only I20 to I23 instructions are shown) are executed, each of which acts on one or more variables in the block. For example, command I20 acts on record variable RV28 in record R1, command I21 acts on record variable RV59 in record R5, and command I22 acts on global variable GV43. Command I23 acts on the global variable GV67. Similarly, processor P2 executes the code in block B1 to act on the variable, processor P3 executes the code in block B8 to act on the variable, and processor P4 executes block B99. Run the code inside the) to act on the variable.

An example of block-oriented software is Telefonaktiebolaget LM Ericsson's Programming Language for Exchanges (PLEX) software, which consists entirely of blocks. Java applications are an example of a real object-oriented design.

Event-level pipeline technique

As already mentioned, some systems handle external events (eg, CP-to-CP buffered signals) in "slices" connected by internal events.

According to a second aspect of the present invention, at least one set of multiple shared-memory processors is executed in parallel by operating in a multiprocessor pipeline where each external event is processed in a slice as a series of events executed at different processor stages of the pipeline. This is done. As long as all signals generated by one stage are provided to the next stage in the same order in which they were generated, the sequencing condition of processing the signals in the generation order is guaranteed. If you deviate from this rule, you need to ensure racing-free execution. If the execution of a given slice results in more than one signal, the signal must be provided to the next processor stage in the same order in which they occurred, or if the signal is distributed to more than one processor, the resultant contention may result. It is necessary to ensure that this calculation is not harmful.

5A-B, an implementation of a given multiprocessor pipeline according to the second aspect of the present invention is now described.

5A is a schematic diagram of a processing system driven by an event according to a second aspect of the present invention. The processing system is similar to that shown in FIG. However, internal events generated by a processor that is part of the multiprocessor pipeline 11 are not necessarily fed back to the same processor, but rather appear as bands that occur in the processors P1 to P4 and terminate on the bus to the event queue 16. As may be provided to any processor.

In an object-oriented software design, the software in the shared memory is organized into blocks or classes as described above with respect to FIG. 4, and upon receipt of an external event, the corresponding processor executes code in the block / object to execute another block / object. It can generate a result in the form of an internal event going to. When the internal event occurs and is executed, it executes on the indicated block / object and generates another internal event destined for another block / object. This series of procedures generally disappears after several internal events. For example, for telecommunications applications, each external event can typically generate 5-10 internal events.

The realization of a multiprocessor pipeline built for object-oriented software design is the allocation of software block / class clusters to processors. In Fig. 2, block / class clusters CL1 to CLn in the shared memory 12 are schematically shown in bands. As can be seen in FIG. 2, one of the clusters CL1 is assigned to the processor P2 (indicated by the solid line interconnecting CL1 and P2), and another cluster CL2 is connected to the processor P4. (As shown by the bands connecting CL2 and P4). In this way, each block / class cluster in the shared memory 12 is assigned to one of the processors P1 to P4, the allocation scheme being a look-up table 17 in the distributor 14. And lookup table 18 in shared memory 12. Each lookup table 17 or 18 connects a target block to each event according to an event ID or the like, and connects each target block to a prescribed block cluster. The distributor 14 distributes external events to the processor according to the information in the lookup table 17. The lookup table 18 in the shared memory 12 can be used by all processors P1 through P4 so that internal events can be distributed to the processors. That is, when the processor generates an internal event, the processor asks the lookup table 18 to assign i) the corresponding target block according to the event ID, etc., ii) the cluster to which the identified target block belongs, and iii) the identified cluster. The processor then decides which processor it is, and sends an internal event signal to the appropriate event queue. It is important to note that although blocks using overlapping clusters can be implemented in more sophisticated ways using information such as execution status in addition to event IDs, each block usually belongs to only one cluster. .

As shown in Figure 5b, pipeline execution occurs automatically by mapping a block / class cluster to a processor-the external event EE is directed to block A which is assigned to the processor P1, and then to the block. The internal event IE generated by is directed to block B which is assigned to processor P2, and then the internal event IE generated by the block is directed to block C which is assigned to processor P4. And the internal event IE generated by the block is directed to a block D allocated to the processor P1. Thus, we have a pipeline that logically has multiple processor stages. Here, blocks A and D are cluster portions mapped to the processor P1, while block B is a cluster portion mapped to the processor P2, and block C is a cluster mapped to the processor P4. Suppose it is part. Each stage in the pipeline runs on one processor, but a given processor may execute more than one stage of the pipeline.

A change is included that maps an event requesting input data from a defined data area in shared memory 12 to the same defined processor set.

When a processor stage in a multiprocessor pipeline executes an event belonging to a series of first events and sends the resulting internal event signal to the next processor stage, it is usually handled by freely starting to process events from the series of subsequent events. It should be noted that the dose is improved.

To get the maximum gain, mapping the pipeline stage to the processor must be done so that all processors are evenly loaded. Thus, block / class clusters are distributed according to "even load" criteria. The amount of time spent in each cluster may be known, for example, from a similar application running on a single processor, or may be monitored during execution time to enable readjustment of distribution. If a block raises more than one internal event in response to an input event, and each event that is directed to a different block results in a "even load" to prevent the "first" execution of an internal event that is "later" than other events In addition to the criteria, a "no racing" criterion is needed.

Of course, internal events can be handled without dividing into slices, but by dividing internal events, structured program development / maintenance and pipeline processing is possible.

In addition, the processing of such an external event may be performed in a few large slices, or may be performed in many small slices.

As mentioned above, there are two basic procedures to ensure data matching when global data is processed by the processor during parallel task execution: i) locking, and ii) collision detection and rollback.

Locking as a means to ensure data matching

When implementing locking for the purpose of ensuring data matching, each processor executing a task typically locks the global data to be used by the task before starting the task execution. In this way, only processors that have locked global data can access it.

Locking is well suited for object-oriented design because the data area is clearly defined so that certain data sectors of one or all blocks can be locked. If there is no general characteristic of global data, such as it is usually impossible to know which part of the global data in a block will be transformed by a given execution sequence or task, then locking the entire global data is a safe way to ensure data matching. . Ideally, it would be sufficient to protect the global data in each block, but for many applications, there are some so-called "across records" that also need to be protected. For example, selecting an empty record actually examines multiple records to find the empty record. Thus, locking the entire block protects everyone. Also, in applications where execution of a buffered signal may span multiple blocks connected by so-called direct / combined signals with the possibility of looping (visiting one block more than once before EXIT), task execution Do not release the block to be locked until you have finished.

The use of NCC generally minimizes the "shared state" between multiple processors, and also improves cache hit rate. In particular, by mapping functionally different area processors / hardware devices, such as signaling devices and subscriber terminals in telecommunication systems, to different processors in the central node, different access mechanisms are usually different until processing reaches the last execution stage. As it is processed in blocks, it is allowed to process different access mechanisms concurrently with little or no waiting for locked blocks.

6 illustrates ensuring data matching using locking of blocks / objects. Suppose three different external events EEx, EEy, and EEz are directed to blocks B1, B2, and B3, respectively. An external event EEx is input to block B1, and the corresponding processor locks block B1 before starting execution in that block, as indicated by the diagonal across block B1. Then, external event EEy is input to block B2, and the corresponding processor locks block B2. As indicated by the time axis t in FIG. 6, the external event EEz directed to the block B1 appears after the external event EEx that has already been input to the block B1 and locked the block. Therefore, the processing of the external event EEz must wait until the block B1 is released.

However, locking may cause deadlocks where two processors wait indefinitely for each other to release variables mutually requested by the processors in their current task execution. Therefore, it is desirable to perform a rollback that avoids or detects a deadlock and ensures progress.

In contrast to occupying / locking blocks when needed during execution, deadlocks can be avoided by occupying all the blocks needed to execute the entire task (also called a task) at the start of the task. However, although non-execution time input using compiler analysis may provide information for minimizing deadlocks, for example, by at least occupying blocks that consume more of the processing time in a task, all that is needed for a given task. Knowing a block in advance may not always be possible. An effective way of minimizing deadlocks is to occupy such highest utilization blocks before starting execution, regardless of whether they are the next block needed for processing. It is always a good idea to occupy the blocks necessary for the task, almost certainly the ones with the highest utilization, and the rest of the blocks when needed.

Occupying a block when necessary during execution tends to cause a deadlock as described above, so it is necessary to detect and resolve the deadlock. It is advantageous to detect deadlocks as soon as possible, and according to the invention deadlock detection can be made almost immediately. Since all "overhead processing" occurs between two jobs, deadlock detection is demonstrated while obtaining "resources" for later jobs that will cause deadlocks. This is done by examining which processor one of the resources required for the task under consideration is held by and then verifying that the processor is waiting for the resource held by the processor with the task under consideration, for example by using a flag per block. .

In addition, minimizing deadlocks affects how rollback and progression occurs. The lower the deadlock frequency, the simpler the rollback method, because you don't have to worry about the efficiency of rare rollbacks. On the other hand, if the deadlock frequency is relatively high, it is important to have an effective rollback scheme.

The basic principle behind rollback is to release all the resources held up and back out to the beginning of one of the tasks involved in deadlocking by undoing all changes made to execution up to this point, ensuring progress without sacrificing efficiency. It is possible to restart the rolled back job later or after the delay. This generally means that the rollback method is not allowed to cause deadlock repetition, which results in a rollback of the same job by restarting immediately, nor should it cause the delay before starting the rolled back operation to be too long. However, if the job execution time is very short, it is appropriate to simply select and roll back the "later" job that causes the deadlock.

Collision detection as a means of ensuring data matching

Implementing conflict detection for the purpose of ensuring data matching, the software is executed in parallel by multiple processors, and access conflicts are detected so that one or more executed tasks for which a conflict is detected can be rolled back and restarted.

It is desirable for each processor to mark variable usage of shared memory while executing a task so that variable access conflicts are detected. At a very basic level, the marker method consists of marking the use of individual variables in shared memory. However, by marking larger areas instead of individual data, coarser collision checking is realized. One way to implement coarser collision checking is to use standard memory management techniques, including paging. Another way is to mark groups of variables, which has proved to be particularly effective for marking entire records, including all record variables in a record, instead of marking individual record variables. However, if the job uses a predetermined data area, it is important to select the "data area" in such a way that it is very unlikely that other jobs will use the same area. If this is not done, sparse data-area marking can actually result in a higher rollback frequency.

7 illustrates detecting access conflicts in object-oriented software design using variable marking. The shared memory 12 is composed of blocks B1 to Bn as described above with respect to FIG. 4, and a plurality of processors P1 to P3 are connected to the shared memory 12. 7 shows two blocks (block B2 and block B4) in more detail. In such a predetermined marker method implementation, each global variable (GV1 to GVn) and each record (R1 to Rn) in the block is associated with a marker field as shown in FIG.

The marker field has one bit for each processor connected to the shared memory system, so in this case each marker field has three bits. All bits are reset at first, and each processor sets its own bits before accessing (reading or writing) a variable or record, and then reads and computes the entire marker field. If there is any other bit set in the marker field, a collision is imminent, and the processor rolls back the task to be executed by canceling all changes made up to this point in time, including resetting all corresponding marker bits. On the other hand, if no other bits are set, the processor continues to execute the task. Each processor records the address of each variable accessed during execution and uses the recorded address to reset its respective bit in the corresponding respective marker field upon completion of task execution.

In order to be able to roll back when a collision is detected, it is necessary to keep all the modified variables (variable state before being transformed) and copies of these addresses during each task execution. In this way, the original state can be restored when rolled back.

In Fig. 7, the processor P2 needs to access the global variable GV1, sets its respective bit at the second position of the marker field associated with GV1 and then reads out the entire marker field. In this case, as field 110 includes bits set by processor P1 and bits set by processor P2, an impending variable access conflict is detected. Processor P2 rolls back the running task. Similarly, if processor P2 needs to access record R2, the processor sets its respective bit in the second position and then reads the entire marker field. As the field 011 contains the bit set by P2 and the bit set by P3, a record access conflict is detected, and the processor P2 rolls back the task being executed. If processor P3 needs to access record R1, the processor first sets its respective bit in the third position of the linked marker field and then reads and calculates the entire field. In this case, no other bits are set at all, allowing the processor P3 to access the record for reading or writing. Each marker field has two bits per processor, one for writing and one for reading, so as to reduce unnecessary rollback, for example, mainly on variables being read.

Another approach for collision detection is called a bungee comparison method, where read and write bungees are compared at the end of a task. The main difference compared to the marker method is that access by other processors is generally not checked during task execution, but only upon completion of the task. Examples of certain types of inspection units implementing the address comparison method are disclosed in international patent application WO 88/02513.

Reuse of Current Application Software

Today's sequentially programmed application software typically represents a large investment, and in the case of single-processor systems such as single-processor nodes at the highest levels of hierarchical processing systems, already thousands or millions of lines Software code exists. Automatically transform application software through recompilation or equivalent to ensure data matching when the application software runs on multiple processors, so that all software code is moved to and reused in a multiprocessor environment, saving time and money. You can save.

8A illustrates a conventional single-processor system seen in a layered view. Downstairs, a processor P1, such as a standard multiprocessor, can be found. The next level includes the operating system, followed by a virtual machine that interprets the application software that can be found at the top level.

8B illustrates a multiprocessor system in a layered view. At the bottom level, multiple shared-memory processors P1 and P2 are found that are implemented as standard off-the-self multiprocessors. Next, the operating system follows. For example, a virtual machine capable of an APZ emulator running on a SUN workstation, a high performance compilation emulator such as SIMAX, or a well-known Java virtual machine can be adapted for multiprocessor support and data-matching support. Sequentially programmed application software typically uses code for data-matching support by post-processing object code if compiled, recompiling blocks / classes, or changing interpreters if interpreted. It is modified by simply adding

When detecting collisions based on variable marking, the following steps can be taken to move application software written for a single-processor system to a multiprocessor environment. Prior to each write access to the variable, code that stores the original state and address of the variable is inserted into the application software to enable proper rollback. Prior to each read and write access to the variable, code is inserted into the software that sets the marker bit in the marker field, examines the marker field, as well as stores the address of the variable. Next, the application software is recompiled or reinterpreted, or the object code is postprocessed. The hardware / operating system / virtual machine is also modified to implement rollback and reset the marker field to provide collision detection related support. Thus, if a collision is detected when executing code to inspect the marker field, control is passed to a hardware / operating system / virtual machine that performs a rollback using the stored copy of the changed variable. In addition, at the end of the task, the hardware / operating system / virtual machine usually takes over and resets the relevant bit of each marker field provided by the storage address of the variable accessed by the task.

It should be noted that statistical analysis of code can minimize the insertion of new code. For example, instead of prior to each read and write as described above, code insertion can be performed in fewer places in such a way that the ultimate goal is met.

If multiple processors are implemented with proprietary hardware in proprietary designs, it should be noted that application software can be moved directly to a multiprocessor environment.

9 is a schematic diagram of a communication system in which one or more processing systems according to the present invention are implemented. The communication system 100 may support different bearer service networks, such as a Public Switched Telephone Network (PSTN), a Public Land Mobile Network (PLMN), an Integrated Service Digital Network (ISDN), and an Asynchronous Transfer Mode (ATM) network. The communication system 100 basically comprises a number of switching / routing nodes 50-1 through 50-6 interconnected by physical links, usually grouped into trunk groups. Switching nodes 50-1 through 50-4 provide access to which access terminals such as telephones 51-1 to 51-4 and computers 52-1 to 52-4 are connected through a local exchange (not shown). Has a point. The switching node 50-5 is connected to a Mobile Switching Center (MSC) 53. The MSC 53 is connected to two Base Station Controllers (BSCs) 54-1 and 54-2 and a Home Location Register (HLR) node 55. The first BSC 54-1 is connected to a plurality of base stations 56-1 and 56-2 in communication with one or more mobile units 57-1 and 57-2. Similarly, second BSC 54-2 is connected to multiple base stations 56-3 and 56-4 in communication with one or more mobile units 57-3. The switching node 50-6 is connected to a host computer 58 equipped with a database system DBS. A user terminal connected to the system 100, such as computers 52-1 to 52-4, can request a database service from a database system in the host computer 58. The server 59, in particular the Java server, is connected to the switching / routing node 50-4. A dedicated network (not shown), such as an office network, may also be connected to the communication system of FIG. 1.

The communication system 100 provides various services to a user connected to a network. Examples of such services include routine telephone calls, messaging services, LAN interconnections, intelligent network (IN) services, ISDN services, computer telephony integration (CTI) services, video conferencing, file transfer, so-called on PSTN and PLMN. Access to the Internet, paging services, video-on-demand, and the like.

In the present invention, each switching node 50 in the system 100 is the first or second aspect of the present invention that handles events such as service requests and internal-node communication (if possible in the form of a matrix processing system). It is preferred to provide a treatment system (1-1 to 106) in accordance with the two aspects combined). The call setup requests, for example, the processing system to execute the task sequence. This task sequence defines the call setup service at the processor level. The processing system according to the invention is also arranged in the MSC 53, the BSCs 54-1 and 54-2, the HLR node 55, and the host computer 58 and the server 59 of the communication system 100, respectively. It is desirable to be.

While the preferred use of the present invention is at high level processor nodes in hierarchical processing systems, those skilled in the art will appreciate that the aspects of the invention described above may be applied to processing driven by any event for which event-flow parallel processing can be identified. You will know that.

The term event-based system includes, but is not limited to, telecommunications, data communications, and transaction-oriented systems.

The term shared-memory processor is not limited to standard off-the-self microprocessors, but any type of hardware, such as SMP and certain hardware, that operates with a common memory trend with data and application software that can access all processing units. A processing unit. This also includes systems in which shared memory is distributed to multiple memory units, and even systems using asymmetric access, wherein access times to different portions of shared memory distributed for different processors may each be different.

It should be noted that the above described embodiments are presented by way of example only, and this does not limit the invention. Modifications, changes, and improvements other than those described above that maintain the basic principles disclosed and claimed herein are included within the scope and spirit of the present invention.

Claims (60)

In a hierarchical distributed processing system (1) based on events having a plurality of processor nodes distributed across multiple system hierarchical levels, One or more high level processor nodes 10 in the hierarchical processing system 1 are: Multiple shared-memory processors (11), Means (14) for mapping external events arriving at the processor node to the processor, where the external event flow is divided into a number of non-switched event categories, with each non-switched event category assigned to a defined set of shared-memory processors Means 14 for mapping to process using the processor of the set, and Event-based hierarchical distributed processing system, characterized in that it comprises means (15) to ensure data matching when global data in the shared memory (12) is processed by the processor. The method of claim 1, Each processor set is a hierarchical distributed processing system based on an event, characterized in that the form of a single processor. The method of claim 1, One or more processor sets are in the form of processor arrays operating in a multiprocessor pipeline with multiple processor stages. Each non-switched category event assigned to each processor set is a sequence of events that is executed at different processor stages in the pipeline. A hierarchical distributed processing system based on events, characterized in that processed in a slice. The method of claim 3, wherein The event-based hierarchical distribution, characterized in that the events requesting input data from the defined data area in the shared memory 12 are mapped to one and the same defined processor set by the mapping means 14, 18. Processing system. The method of claim 1, The non-exchange category is a hierarchical distributed processing system based on an event, characterized in that the order of events within a category is maintained but there is no ordering condition for processing events of different categories. The method of claim 1, And said high level processor node further comprises means for feeding events generated by one processor set to the same processor set. The method of claim 1, And said non-exchange category is defined by an event from a defined source (S1 / S2). The method of claim 7, wherein And the source (S1 / S2) is an input port, a lower level processor node, or a hardware device connected to the hierarchical distributed processing system. The method of claim 1, The data matching means 15 comprises means for locking a global variable in a shared memory to be used by a software task executed in response to an event, and means for releasing the locked global variable upon completion of task execution. Event-based hierarchical distributed processing system. The method of claim 9, The data matching means 15 further comprises means for releasing and appropriately delaying the locked global variables of one of the two tasks locking each other and restarting the task. Distributed processing system. The method of claim 1, The software in the shared memory 12 includes a plurality of software blocks (B1 through Bn), each of the processors executing a software task that includes a software block in response to an event, and each processor, before starting the task execution, Means for forming at least a portion of the data coincidence means (15) that locks at least global data in the block so that only the processor that has locked the block can access the global data in the block. Distributed processing system. The method of claim 11, And said locking means locks the entire software block before starting the corresponding task execution and releases the locked block upon completion of the task execution. The method of claim 11, And said locking means minimizes deadlocks by at least occupying blocks required for software tasks that consume a large portion of processing time within a task before starting execution of the task. The method of claim 11, The high level processor node includes means for detecting a deadlock and means for releasing and appropriately delaying a block locked by one of the waiting processors and then restarting a software task executed by the processor to ensure progress. Event-based hierarchical distributed processing system comprising a. The method of claim 14, The deadlock detection means includes means for checking whether a variable required for a software task under consideration is locked by another processor, and means for verifying whether the other processor is waiting for a variable locked by a processor having a task under consideration. Event-based hierarchical distributed processing system comprising a. The method of claim 1, The multiprocessor 11 individually processes the events and executes a corresponding number of software tasks in parallel, and the data matching guarantee means 15 cancels the means for detecting a conflict between the parallel tasks and the task for which the conflict is detected. Event-based hierarchical distributed processing system, characterized in that it comprises a means for restarting. The method of claim 16, Wherein each processor comprises means for marking variable usage in a shared memory, and wherein the collision detection means comprises means for detecting variable access conflicts based on the marking. Processing system. The method of claim 16, The software in the shared memory 12 includes a plurality of software blocks (B1 through Bn), each of the multiple processors executes a software task including the software block in response to an event, and each processor marks the use of variables in the block. Means for detecting a variable access collision based on said marking. The method of claim 1, The high level processor node 10 further comprises a parallel event queue 16 with one queue directed to each processor set, the mapping means 14 being external based on the information contained in each external event. A hierarchical distributed processing system based on events characterized by mapping events to event queues. In a hierarchical distributed processing system (1) based on events having a plurality of processor nodes distributed across multiple system hierarchical levels, One or more high level processor nodes 10 in the hierarchical processing system are: Multi-shared-memory processor 11 operating as a multiprocessor pipeline with multiple processor stages, where each event reaching the multiprocessor pipeline is processed in a slice as a series of events executed at different processor stages in the pipeline. Multiple shared-memory processors (11), Event-based hierarchical distributed processing system, characterized in that it comprises means (15) to ensure data matching when global data in the shared memory (12) is processed by the processor. The method of claim 20, The software in the shared memory 12 comprises a plurality of software blocks B1 to Bn, each event directed to one of the software blocks, The multiprocessor pipeline comprises means (17, 18) for allocating a block cluster (CL) to each processor in a load-balancing manner, and means (17, 18) for mapping events to processors in accordance with the assignment made by the allocation means. Event-based hierarchical distributed processing system, characterized in that is implemented as). The method of claim 20, The data matching means 15 comprises means for locking a global variable in a shared memory to be used by a task executed by a processor in response to an event, and means for releasing the locked global variable upon completion of the task execution. Event-based hierarchical distributed processing system comprising a. The method of claim 22, The data matching means (15) further comprises means for restarting the task after releasing and appropriately delaying a global variable of one of the two tasks locking with each other. The method of claim 20, The software in the shared memory 12 includes a plurality of software blocks (B1 through Bn), each of the processors executing a software task including the software block in response to an event, wherein each processor is at least software before starting the task execution. Means for forming a portion of the data coincident guarantee means (15) that locks the global data of the block so that only the processor that locks the block has access to the global data in the block. Distributed processing system. The method of claim 24, And said locking means locks the entire software block before starting execution of the corresponding task and releases the locked block upon completion of the task execution. The method of claim 24, And said locking means minimizes deadlocks by at least occupying blocks necessary for software tasks that consume a large portion of task processing time before starting task execution. The method of claim 24, The high level processor node 10 proceeds by means of detecting a deadlock and by releasing and appropriately delaying a block locked by one of the waiting processors and restarting a software task executed by the processor. An event-based hierarchical distributed processing system comprising means for ensuring. The method of claim 27, The deadlock detection means includes means for checking whether a variable required for the software task under consideration is locked by another processor and means for verifying whether the other processor is waiting for a variable locked by the processor having the task under consideration. Event-based hierarchical distributed processing system characterized in that the. The method of claim 20, The multiprocessor 11 processes the events individually and executes a corresponding number of software tasks in parallel, and the data matching guarantee means 15 cancels the task for which the collision is detected and the means for detecting the collision between the parallel tasks. Event-based hierarchical distributed processing system, characterized in that it comprises a means for restarting. The method of claim 29, Wherein each processor comprises means for marking variable usage in shared memory 12, and wherein the collision detection means includes means for detecting variable access conflicts based on the marking. Hierarchical distributed processing system. A processing method of a distributed processing system (1) based on an event having a plurality of processor nodes distributed over a plurality of system layer levels, Providing multiple shared-memory processors 11 to one or more high level processor nodes 10 in the hierarchical processing system 1, Separating the external event flow to the processor node into multiple non-exchange categories (NCCs) of events based on the event-flow parallelism identified in the system, Mapping each NCC to a processor so that each NCC of the event is assigned to a prescribed set of multiple processors and processed using the processors of the set, and Ensuring data matching when the global data in the shared memory (12) is processed by the processor such that only one processor accesses the predetermined global data at a time. The method of claim 31, wherein The NCC is a method of processing a hierarchical distributed processing system, characterized in that the order of events must be maintained in a category but no ordering conditions exist in processing events of different categories. The method of claim 31, wherein One or more processor sets operate as a multiprocessor pipeline with multiple processor stages, each of the events in a non-switched category assigned to the processor set processed in a slice as a series of events executed on different processor stages in the pipeline. Method of processing a hierarchical distributed processing system, characterized in that the. The method of claim 31, wherein A method for processing a hierarchical distributed processing system, characterized by supplying events generated by one processor set to the same processor set. The method of claim 31, wherein The step of ensuring data matching includes locking a global variable in shared memory to be used by software executed in response to an event, and releasing the locked variable upon completion of a software task execution. A method of processing a hierarchical distributed processing system. 36. The method of claim 35 wherein The step of ensuring data matching further comprises the step of releasing and appropriately delaying a global variable of one of the two locking tasks, and restarting the task. The method of claim 31, wherein The software in the shared memory 12 includes a plurality of software blocks, each of the processors executing a software task including the software blocks in response to an event, and the step of ensuring the data match is performed before being executed by one processor. Locking at least global data of a software block such that only the processor can access global data in the block. The method of claim 37, Wherein said entire software block is locked before starting execution of a corresponding task, and said locked block is released upon completion of said task execution. The method of claim 37, A method of processing a hierarchical distributed processing system, characterized by avoiding so-called deadlocks by occupying all blocks necessary for a software task before starting task execution. The method of claim 37, Detecting a deadlock, releasing a block locked by one of the waiting processors, and restarting a software task executed by the processor after a prescribed delay to ensure progress. Treatment method. The method of claim 31, wherein The processor executes a plurality of corresponding software tasks in parallel in response to an event, wherein assuring data matching includes detecting an access conflict and canceling and restarting the task for which the conflict is detected. Processing method of a hierarchical distributed processing system. 42. The method of claim 41 wherein Wherein each of the processors marks the use of a variable in shared memory, and wherein the collision detection step includes detecting a variable access conflict based on the marking. The method of claim 31, wherein And the method further comprises transferring application software for a single-processor system to multiple shared-memory processors and executing accordingly. A method of processing a hierarchical distributed processing system based on an event having a plurality of processor nodes distributed across a plurality of system layer levels, Providing a plurality of shared-memory processors 11 to one or more high level processor nodes 10 in the hierarchical processing system 1, Operating a multiprocessor 11 with a multiprocessor pipeline having multiple processor stages, wherein one or more events arriving at the multiprocessor pipeline are processed in the slice as a series of events executed at different processor stages of the pipeline. Steps, and Ensuring data matching so that only one processor accesses the global data at a time when global data in shared memory is processed by a multiprocessor. The method of claim 44, The software in the shared memory 12 includes a plurality of software blocks (B1 to Bn), each event directed to one of the software blocks, and operating the processor in a multiprocessor pipeline, in a load balancing manner. And assigning a cluster (CL) to each of the processors and mapping the events to the processors according to the allocation. The method of claim 44, Ensuring data matching includes locking a global variable in shared memory to be used by software executed in response to an event, and releasing the locked global variable upon completion of a software task execution. A method of processing a hierarchical distributed processing system. The method of claim 46, The step of ensuring data matching further comprises the step of releasing and appropriately delaying a global variable of one of the two locking tasks, and restarting the task. The method of claim 44, The software in the shared memory 12 includes a plurality of software blocks, each of the processors executing a software task including the software blocks in response to an event, and ensuring the data match is at least before being executed by one processor. Locking the global data of a software block such that only the processor has access to global data in the block. 49. The method of claim 48 wherein Wherein the entire software block is locked before starting the corresponding task execution, and the locked block is released upon completion of the task execution. 49. The method of claim 48 wherein A method of processing a hierarchical distributed processing system, characterized by avoiding so-called deadlocks, by occupying all blocks necessary for a software task before starting the task execution. 49. The method of claim 48 wherein Detecting a deadlock, releasing a block locked by one of the waiting processors to ensure progress by restarting a software task executed by the processor after a defined delay. Treatment method. The method of claim 44, The processor executes a plurality of corresponding software tasks in parallel in response to an event, and assuring data matching includes detecting an access conflict between parallel tasks to cancel and restart the task for which the conflict was detected. A method of processing a hierarchical distributed processing system characterized by the above-mentioned. The method of claim 52, wherein Wherein each processor marks the use of a variable in shared memory, and wherein the collision detection step includes detecting a variable access collision based on the marking. The method of claim 44, And the method further comprises moving application software for a single-processor system to multiple shared-memory processors and executing accordingly. Multiple shared-memory processors 11 that execute multiple tasks in parallel, A mapper 14 for mapping parallel categories for external independent event signals to multiple processors 11 to execute corresponding tasks in parallel, A collision detector for detecting access conflicts between parallel tasks when global data in shared memory is processed by a processor, and Means for canceling and restarting a job for which a conflict was detected to ensure data matching. The method of claim 55, And means for feeding a task generated by one processor to the same processor. A multiple shared-memory processor 11 that executes multiple tasks in parallel, operating as a multiprocessor pipeline with multiple multiprocessor stages, wherein each external event signal reaching the multiprocessor pipeline is different from the pipeline. A multiple shared-memory processor 11, which is processed in a slice as a series of tasks executed at the processor end, A collision detector for detecting access conflicts between parallel tasks when global data in shared memory is processed by a processor, and Means for canceling and restarting a job for which a conflict was detected to ensure data matching. Shared memory 12 containing software in the form of a plurality of software blocks, Multiple shared-memory processors (11), each for executing in parallel a task associated with one or more software blocks, Means (17, 18) for allocating a cluster (CL) of software blocks to each processor, Means (17, 18) for distributing work to the processor for execution based on the allocation made by the assigning means, and Means (15) for ensuring data matching when global data in shared memory is processed by a multiprocessor. A communication system (100) comprising a hierarchical distributed processing system (1) based on events having a plurality of processor nodes distributed across multiple system hierarchical levels, One or more high level processor nodes 10 in the hierarchical processing system are: Multiple shared-memory processors (11), Means 14 for mapping external events arriving at the processor node to the processor, wherein the external event flow is divided into a plurality of non-exchange event categories, and the non-exchange event categories are assigned to a prescribed set of shared-memory Means (14) for mapping to be processed using a set of processors, and And means (15) to ensure data matching when global data in the shared memory (12) is processed by the processor. A communication system (100) comprising a hierarchical distributed processing system (1) based on events having a plurality of processor nodes distributed across multiple system hierarchical levels, One or more high level processor nodes 10 in the hierarchical processing system are: Multi-shared-memory processor 12 operating in a multiprocessor pipeline with multiple processor stages, where each event reaching the multiprocessor pipeline is processed in a slice as a series of events executed at different processor stages in the pipeline. Multiple shared-memory processors 12, and And means (15) to ensure data matching when global data in the shared memory (12) is processed by the processor.