Synchronization mechanism for inter-process communication

Abstract

An apparatus, system and method are disclosed for accelerating synchronization during inter-process communication of concurrent processes executed by an operating system (OS) of a computer including at least one CPU core, whereby the OS maps the processes onto the at least one CPU core. The apparatus comprises: a management module configured to register and maintain a list of at least one first process in a waiting state to obtain access to contention resources shared with a second process; a notification interface configured to receive a release notification from the second process, the second process releasing the contention resource; and a wake-up module configured to request the OS to wake up a subset of the at least one first process in the waiting state after receiving the release notification from the second process.

Description

Technical Field

[0001] This disclosure relates to, for example, synchronizing processes in a computer system within the field of computer architecture. This disclosure proposes a device for accelerating the synchronization of concurrent processes executed by an operating system (OS) of a computer including at least one CPU core, whereby the OS maps processes to at least one CPU core. This disclosure also proposes a system including the device and a method for accelerating the synchronization of concurrent processes executed by the OS. Background Technology

[0002] In modern on-chip systems, an increasing number of CPU cores and accelerators are interconnected. To benefit from the performance and modularity of multi-core systems, modern applications are designed with multiple processes / threads operating in parallel (or concurrently) that interact and cooperate. These applications running on such systems need to exchange information / messages between different computing units. This mechanism is commonly referred to as Inter-Process Communication (IPC). IPC is based on a message-passing model or shared memory with synchronization mechanisms to ensure not only the exchange of data or messages between processes or threads, but also timely, synchronous, and reliable exchange. For this purpose, synchronization mechanisms must ensure that multiple processes join or handshake to properly manage concurrency in multi-producer, multi-consumer relationships and ensure that these multiple processes are granted exclusive access to resources shared by concurrent processes or threads, for example. IPC is typically provided by the operating system (kernel) as a service for applications running on the operating system.

[0003] IPC performance is becoming increasingly important because it constitutes a major limitation / bottleneck for performance scalability in multi-core systems. Current solutions for improving IPC performance are primarily software or hardware-based. Software solutions offer flexibility but typically require thousands of cycles for efficient execution regarding synchronization and IPC, and are only available for rich operating systems such as Linux or the more widely used POSIX. On the other hand, all-hardware solutions are only available for dedicated microkernels and nanokernels. These solutions offer high performance but are difficult to integrate into modern rich OSes due to too many integration constraints and limitations. This approach is only suitable for simple systems like real-time systems.

[0004] There are no existing solutions to accelerate IPC by using hardware from POSIX-compliant systems, such as Linux, that can be easily integrated into existing systems using a generic approach. The software legacy issues of complex operating systems require a solution that minimizes the impact on the existing software ecosystem with minimal software changes. Summary of the Invention

[0005] In view of the above, this disclosure aims to accelerate synchronization used during IPC processes. One object of this disclosure is to offload the components of IPC synchronization from the operating system to a hardware accelerator. Another object of this disclosure is to design hardware accelerators that can be easily integrated into modern POSIX operating systems such as Linux to accelerate IPC, such as the synchronization component.

[0006] These and other objectives are achieved through the solutions provided by this disclosure as described in the independent claims. Advantageous implementations are further defined in the dependent claims.

[0007] A first aspect of this disclosure provides an apparatus for accelerating synchronization during inter-process communication of concurrent processes executed by an operating system (OS) of a computer including at least one CPU core, whereby the OS maps the processes to the at least one CPU core. The apparatus includes: a management module configured to register and maintain a list of at least one first process in a waiting state to gain access to a contentious resource shared with a second process; a notification interface configured to receive a release notification from the second process, the second process releasing the contentious resource; and a wake-up module configured to request the OS to wake up any one of the at least one first process in the waiting state upon receiving the release notification from the second process.

[0008] In one implementation of the first aspect, the waiting state includes, for example, waiting for the contentious resource to become available once the lock or semaphore is released, or waiting for a condition variable to be modified, or waiting for a synchronization barrier to complete.

[0009] In one implementation of the first aspect, the wake-up module is further configured to: enqueue information of the subset of the at least one first process to be woken up into the wake-up list of the OS, and send an interrupt signal to the CPU core.

[0010] In one implementation of the first aspect, the access to the contentious resource is a write or read access.

[0011] In one implementation of the first aspect, the condition variable includes a full or empty value related to the filling state of the contested resource.

[0012] In one implementation of the first aspect, the wake-up module is further configured to: monitor lost wake-ups, wherein the lost wake-ups include a process that, when the OS is requested to wake up the process, has been sent to a waiting state but is not yet in the waiting state.

[0013] In one implementation of the first aspect, the device further includes a storage module configured to store information about the contentionable resource, the at least one CPU core, and the at least one first process and the second process.

[0014] In one implementation of the first aspect, the resource is a shared data structure in memory used for exchanging information between processes in a thread-safe manner, such as a circular buffer, FIFO, or queue, or any other memory structure that enables data exchange during inter-process communication.

[0015] In one implementation of the first aspect, the shared data structure includes: a circular buffer, a FIFO or a queue, or any other memory structure that enables data exchange during inter-process communication.

[0016] A second aspect of this disclosure provides a system comprising: a device according to the first aspect; a kernel driver for the device, the kernel driver being configured to integrate the device into the operating system; and a synchronization library configured to use the device to provide an abstraction layer to applications performing IPC operations.

[0017] In one implementation of the second aspect, the synchronization library is configured to send a release notification from a second process and redirect the release notification to the device's notification interface instead of the OS.

[0018] A third aspect of this disclosure provides a method for accelerating synchronization during inter-process communication of concurrent processes executed by an operating system (OS) of a computer including at least one CPU core, whereby the OS maps the processes to the at least one CPU core. The method includes the steps of: registering and maintaining a list of at least one first process in a waiting state to gain access to a contentious resource shared with a second process; receiving a release notification from the second process, the release notification including the release of a lock or semaphore, modification of a condition variable, or completion of a synchronization barrier; and waking up a subset of the at least one first process in the waiting state after receiving the release notification from the second process.

[0019] A fourth aspect of this disclosure provides a computer program comprising instructions that, when executed by a computer, cause a device according to the first aspect to perform steps of the method according to the third aspect.

[0020] It should be noted that all devices, elements, units, and apparatuses described in this application can be implemented in software or hardware elements or any combination thereof. All steps performed by the various entities described in this application, and the functions to be performed by the various entities described, are intended to mean that the respective entities are suitable for or configured to perform the respective steps and functions. Although the specific functions or steps to be performed by external entities are not reflected in the detailed description of the specific elements of the entities performing the specific steps or functions in the following detailed description of embodiments, those skilled in the art will understand that these methods and functions can be implemented in the corresponding software or hardware elements or any combination thereof. Attached Figure Description

[0021] The above aspects and implementations will be explained in the following detailed description of the embodiments, taken in conjunction with the accompanying drawings, in which:

[0022] Figure 1 Two series of IPC mechanisms based on existing technology are shown.

[0023] Figure 2 Two features required for the IPC process according to the prior art are shown.

[0024] Figure 3 An IPC process based on existing technology is shown.

[0025] Figure 4 An example of a synchronization mechanism based on existing technology is shown.

[0026] Figure 5 The timeline of the release of a contention lock shared between two threads in accordance with an embodiment of this disclosure is shown.

[0027] Figure 6 An apparatus for accelerating the synchronization of concurrent processes according to an embodiment of the present disclosure is shown.

[0028] Figure 7 The interaction between a hardware accelerator and its software environment according to an embodiment of this disclosure is illustrated.

[0029] Figure 8 The integration of a hardware accelerator with its computing environment according to an embodiment of this disclosure is illustrated.

[0030] Figure 9 A system for accelerating IPC synchronization according to an embodiment of this disclosure is shown.

[0031] Figure 10 Another system for accelerating IPC synchronization is shown according to an embodiment of this disclosure.

[0032] Figure 11 The interaction between a writer process and a reader process for a shared public resource according to an embodiment of this disclosure is illustrated.

[0033] Figure 12 A method for accelerating the synchronization of concurrent processes according to an embodiment of this disclosure is shown. Detailed Implementation

[0034] Figure 1 This illustrates two types of inter-process communication (IPC) that require synchronization according to existing technology. Two processes can share a common process region (shared memory system) or exchange messages with each other (message passing system). For example, in a shared memory system, process P1 accesses its shared region to write data 1, while process P2 reads data 2 from the shared region. Similarly, in a message passing system, process P1 sends a message to the kernel, which relays the message to process Ps. In both cases, the processes P1 and P2 involved must synchronize memory access or message passing so that process P1 is aware of the operations performed by process P2, and vice versa, to avoid memory conflicts or lost messages.

[0035] Figure 2 The diagram illustrates two features required for an IPC process according to existing technology. The first feature, "data transfer / sharing," consists of the exchange of data / messages in a message-passing system or the sharing of data in a shared memory system. The second feature, "synchronization," ensures the correct timing of data / message transfers between two processes or the sharing of data stored in common resources between two processes.

[0036] Figure 3 This paper provides an overview of the different implementations of two basic IPC processes (i.e., message passing and memory sharing) in the Linux operating system.

[0037] Figure 4 An example of a synchronization mechanism based on existing technology is shown. Synchronization is a crucial feature, especially in parallel programming and multi-core architectures. Synchronization ensures that multiple processes join or handshake and each has exclusive access to shared resources to properly manage concurrency in the multi-producer, multi-consumer relationships of processes in the aforementioned computing environment. Specifically, synchronization is responsible for ensuring efficient sharing of data in IPC and therefore must support critical section locks 43, which guarantees that only one process is updating shared structures and condition variables 44, forcing processes to wait until a specific condition is met.

[0038] If there is no contention for shared data, synchronization can be fully supported by the OS / kernel42, such as epoll Linux synchronization, or delegated to user applications (or libraries)41, such as futex (short for "fast user-space mutual exclusion"). The use of futex controls the synchronization measures between processes. Figure 4 Contention occurs when more than two processes compete for the same resource, as described in the diagram. Shared data structures or resources can be circular buffers, FIFOs, queues, or any other memory structure that enables data exchange during IPC.

[0039] This disclosure provides a hardware-based solution for accelerating (e.g., but not limited to, the described IPC synchronization) using two synchronization methods, namely locking critical sections to grant exclusive access and waiting for condition variables. Furthermore, this disclosure improves the OS implementation of synchronization between processes and / or threads. Moreover, this innovation requires virtually no changes to the application and kernel to be integrated.

[0040] Figure 5 The timeline of the release of a contention lock shared between two threads in accordance with an embodiment of this disclosure is shown. Figure 5 The right-hand section (“Using the Accelerator”) shows a hardware accelerator (HWACC) that enhances the synchronization between thread 1 and thread 2, as shown in... Figure 5 The same procedure is performed as shown in the prior art on the left (“Software”). According to the prior art, a process or thread (referred to as thread 2 in this example) must release the lock upon completion of its operation on the shared resource so that waiting processes (“waiters”) can be awakened to perform their tasks utilizing the shared resource. This is achieved by executing a system call (often abbreviated as “syscall”), in this case, a programmatic way in which a computer program or process (thread 2) requests a service from the kernel of the operating system in which it is executing (see [link to relevant documentation]). Figure 5 (The area circled on the left). Services requested from the operating system include notifying thread 1 that a lock on a shared resource has been released by thread 2. In this example in the prior art, since the execution of thread 1 and thread 2 is mapped to their respective CPU cores, the operating system notifies thread 1 by sending an inter-processor interrupt (IPI). Therefore, using this special type of interrupt, if the interrupt handler needs action from another processor, one processor in a multiprocessor system can interrupt another processor via this special type of interrupt. However, two threads can also be mapped to a single CPU core.

[0041] The drawback of this existing synchronization scheme is that syscalls are costly in terms of execution time, especially when more than one thread is waiting to gain access to a shared resource. Figure 5 In the embodiment of this disclosure shown, the hardware accelerator (HW ACC) enhances synchronization as performed in the prior art by accelerating the wake-up sequence, which is initiated by thread 2 executing the aforementioned syscall to the operating system ("releasing the lock when there are waiters"). Figure 5 (The area circled on the left). First, the syscall or release notification is redirected to the hardware accelerator. This prevents the wake-up thread (thread 2) from calling the kernel via syscall to obtain the notification and instructs it to initiate the wake-up sequence by only calling thread 2's synchronization library. Due to this redirection, thread 2 can use the hardware accelerator to offload the wake-up sequence / process and relieve the wake-up waiting thread of its responsibilities.

[0042] Figure 6 An apparatus 60 for accelerating the synchronization of concurrent processes according to an embodiment of the present disclosure is shown. Specifically, the apparatus is adapted to accelerate the synchronization during IPC of concurrent processes executed by an operating system (OS) of a computer including at least one CPU core, whereby the OS maps processes to at least one CPU core. The apparatus includes: a management module 61 configured to register and maintain a list of at least one first process in a waiting state to gain access to a contentionable resource shared with a second process; a notification interface 62 configured to receive a release notification from a second process that releases the contentionable resource; and a wake-up module 63 configured to request the OS to wake up a subset of the at least one first process in a waiting state upon receiving a release notification from the second process.

[0043] Figure 7 The illustration shows the interaction between a hardware accelerator 60 and its parallelized computing environment, represented by concurrent processes A and B, according to an embodiment of this disclosure. This disclosure can accelerate Linux futex (short for "Fast User-Space Mutual Exclusion"), which controls synchronization measures between processes A and B according to existing technology. Futex is used to implement high-performance IPC in parallel programming. Futex is a building block for high-level lock abstractions such as semaphores and POSIX mutexes (short for "mutual exclusion") or condition variables. Futex is typically abstracted through system libraries such as the Native POSIX Thread Library (NPTL).

[0044] A futex consists of a wait queue in kernel space 72, which is connected to atomic integers in user space 71. Essentially, a futex acts as a counter in shared memory, which can be atomically incremented and decremented, and is a computational expression used to describe one step at a time. For example, a process can then wait for the value to become positive before accessing a shared resource. When only process A exchanges messages or shared memory space with process B (non-contention situation), processes or threads in the prior art typically operate entirely on atomic integers in user space 71 using atomic operations to avoid the mutual interference mentioned above. If the kernel needs to intervene in arbitration between multiple processes A—multiple processes A competing for access to a resource about to be released by process B (contention situation)—the process or thread simply requests operation on the wait queue using a relatively expensive syscall (outside user space) involving kernel operation 74. The kernel then wakes up some of the waiting processes A, and / or, if multiple processes B are also competing for the same resource, places the current process B into the wait queue.

[0045] according to Figure 7 The embodiments shown in this disclosure support both contention-free and contention-free scenarios. In a contention-free scenario where synchronization is performed in user space 71, the process does not need to communicate with the hardware accelerator 60 of this disclosure. In this case, the hardware accelerator 60 can support synchronization in user space 71 via user space memory.

[0046] In the event of contention during synchronization in kernel 72, the hardware accelerator 60 according to this disclosure accelerates synchronization between multiple processes A and multiple processes B compared to methods used in the prior art and described above. To this end, the hardware accelerator 60 is configured to receive notifications of the release of blocked shared resources, such as... Figure 7 The middle arrow "wake up" indicates that process A releases the shared resource after accessing and / or modifying it. Due to this feature, a syscall request to kernel operation 74 on the wait queue is no longer needed to wake up the waiting process, as the release notification is redirected (see [link]). Figure 7 The middle arrow pointing to "HW Accelerator" ("wake-up") directs the device to the hardware accelerator instead of redirecting to the kernel / OS. This execution path via the hardware accelerator 100 reduces wake-up costs by 90%.

[0047] The hardware accelerator according to this disclosure provides a novel mechanism for waking up futex-based wait processes by remaining in user mode / space 71 and preventing the overhead of syscalls involving resource-intensive kernel operations.

[0048] The hardware accelerator according to this disclosure can be integrated into multi-core and many-core systems by configuring the hardware accelerator to interact with the CPU core, memory, and interrupt controller, with the process to be synchronized executing on the CPU core and the CPU core managing wait / wake-up notifications to the hardware accelerator 60, the memory storing user / kernel structures primarily used by software but also accessed by the hardware accelerator, and the interrupt controller interrupting the CPU core and triggering kernel-related interrupt handlers.

[0049] Figure 8 It shows the basis Figure 6 The hardware accelerator is integrated with its computing environment in an exemplary manner. As an example, but not limited to, the hardware accelerator of this embodiment may include the following architecture to perform the aforementioned interactions with its hardware environment (such as CPU cores, memory, and interrupt controllers). The management module 81 may be configured to operate as a Futex manager by registering and maintaining a list of threads / processes waiting on the futex. The notification interface 82 may be configured to operate as a configuration interface by handling CPU core configurations and notifications. The wake-up module 83 may be configured to operate as a wake-up engine, which wakes up threads / processes waiting on the futex after receiving a notification that the futex has been released. Figure 8 Exemplary implementations of the hardware accelerator may also include an internal storage device that stores information related to futex, CPU cores, and threads / processes. However, the internal storage device can be as follows: Figure 8 The distribution shown is across multiple storage modules, or it can be separated and integrated into separate modules. Figure 6 The storage areas in the management module, notification interface, and wake-up module are used to provide the associated modules / interfaces of the management module, notification interface, and wake-up module with the information required to perform their tasks, as mentioned above. Figure 8 As described in the paragraph. However, once Figure 6 The tasks to be performed by the management module 61, notification interface 62, and wake-up module 63 are known, and the specific manner in which the storage device is provided is within the common sense of a person skilled in the art.

[0050] Figure 9 A system 90 for accelerating IPC synchronization according to an embodiment of the present disclosure is shown. The system includes: Figure 6 The hardware accelerator 60, the kernel driver 92 configured to integrate the device into the operating system, and the synchronization library 91 configured to provide an abstraction layer to applications that call the execution library.

[0051] Figure 10 It shows the basis Figure 9System 90 is another system used to accelerate IPC synchronization. In this embodiment, the acceleration of the IPC mechanism can be implemented transparently to existing applications and may include... Figure 9 The three components are configured as follows:

[0052] • A modified synchronization library 91 is used to provide an abstraction layer to applications for seamless integration with the final application.

[0053] • Kernel driver 92 for accelerator systems to provide seamless integration into the operating system.

[0054] • Hardware accelerator device 60, which communicates with the CPU core to offload IPC synchronization from the CPU core and operating system.

[0055] For example, the above implementation can be used to accelerate a known IPC structure known as a queue or circular buffer 45. A queue or circular buffer is a simple data structure that implements a First-In-First-Out (FIFO) ordering protocol, which guarantees that messages from the same sender are delivered in the order they were sent. A circular buffer is typically defined using read pointers, write pointers, and capacity. These pointers define the position for reading or writing and whether the queue is full or empty. These pointers are shared among all readers and writers in the queue. Manipulating the pointers requires exclusive access to ensure that two or more processes cannot write to the same slot in the queue or corrupt the queue. Exclusive access can be implemented using futex.

[0056] The example below illustrates a simplified enqueue / dequeue operation based on p-threads (posix threads, pthreads) implemented in Linux, which can be accelerated using the implementation described above.

[0057]

[0058] Figure 11 The illustration depicts the interaction between a writer process (or enqueuing process) and a reader process (or dequeuing process) sharing a public resource under contention conditions, according to an embodiment of this disclosure. The depicted scenario considers two types of process contention: contention for enqueuing processes and contention for dequeuing processes, such as... Figure 11 As shown on the left and right sides.

[0059] The contention situation for the queues described is as follows:

[0060] • This queue has been locked for 1' by a certain process because the supplementary process it interacts with (in Figure 11 (On the opposite side) during writing or reading 3. The pointer value is being updated. The process needs to wait for the lock to be released 5' before it can continue its supplementary operations.

[0061] • The queue is full (2'), as shown in dequeue process (4'). Although the lock has been released, the enqueue process cannot enqueue elements and must wait for the dequeue process to release slot (3).

[0062] • When the queue is empty (2'), as shown in the enqueue process (4'), the dequeue process cannot dequeue the element and needs to wait for the enqueue process to push the element (3).

[0063] In these contention scenarios, a notification must be sent when releasing a lock, pushing a new element, or releasing a slot in a queue. Figure 11 All of these notifications, depicted by the dashed line, are accelerated by the HW accelerator.

[0064] Figure 12 A method 120 for accelerating synchronization of concurrent processes according to an embodiment of this disclosure is illustrated. Specifically, the method is applicable to accelerating synchronization during IPC of concurrent processes executed by an operating system (OS) of a computer including at least one CPU core, whereby the OS maps processes to at least one CPU core. The method includes the steps of: registering and maintaining 121 a list of at least one first process in a waiting state to obtain access to a contentious resource shared with a second process; receiving 122 a release notification from the second process, the release notification including the release of a lock or semaphore, modification of a condition variable, or completion of a synchronization barrier; and waking up 123 a subset of the at least one first process in a waiting state after receiving the release notification from the second process.

[0065] The devices described above may include processors or processing circuitry systems (not shown) configured to perform, conduct, or initiate various operations of the devices described herein. The processing circuitry system may include hardware and / or may be software-controlled. The hardware may include analog or digital circuitry systems, or both. The digital circuitry system may include components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. The devices may also include memory circuitry systems storing one or more instructions executable by a processor or processing circuitry system, particularly under software control. For example, the memory circuitry system may include a non-transitory storage medium storing executable software code that, when executed by the processor or processing circuitry system, causes various operations of the devices to be performed. In one embodiment, the processing circuitry system includes one or more processors and non-transitory memory connected to one or more processors. The non-transitory memory may carry executable program code that, when executed by one or more processors, causes the devices to perform, conduct, or initiate the operations or methods described herein.

[0066] This disclosure has been described in conjunction with various embodiments as examples and implementations. However, based on a study of the drawings, this disclosure, and the independent claims, those skilled in the art will be able to understand and implement other variations when implementing the claimed subject matter. In the claims and the specification, the word "comprising" does not exclude other elements or steps, and the indefinite articles "a" or "an" do not exclude a plurality. A single element or other unit may fulfill the function of several entities or items recited in the claims. The fact that certain measures are recited in dissimilar dependent claims does not indicate that a combination of these measures cannot be used in advantageous implementations.

Claims

1. A device for accelerating synchronization during inter-process communication (IPC) of concurrent processes executed by an operating system (OS) of a computer comprising at least one CPU core, whereby the OS maps the processes onto the at least one CPU core, the device comprising: a management module configured to register and maintain a list of at least one first process that is in a waiting state to obtain access to a contention resource shared with a second process; a notification interface configured to receive a release notification from the second process, the second process releasing the contention resource; as well as A wake-up module is configured to request the OS to wake up the subset of the at least one first process in the waiting state after receiving the release notification from the second process.

2. The device according to claim 1, wherein: The wait state includes waiting for the contention resource to be available once a lock or semaphore is released, or waiting for a condition variable to be modified, or waiting for a synchronization barrier to complete.

3. The device according to any one of the preceding claims, wherein: The wake-up module is further configured to: queue information of the subset of the at least one first process to be awakened into a wake-up list of the OS, and send an interrupt signal to the CPU core.

4. The device according to any one of the preceding claims, wherein: The access to the contended resource is a write or a read access.

5. The device according to any one of the preceding claims, wherein: The condition variable includes a full value or an empty value related to a fill status of the contention resource.

6. A device according to any one of the preceding claims, wherein: The wake-up module is further configured to: A lost wakeup is monitored, wherein the lost wakeup includes a process that has been sent to a wait state but is not yet in the wait state when the OS is requested to wake up the process.

7. A device according to any one of the preceding claims, wherein: The device also includes a storage module configured to store information about the contention resource, the at least one CPU core, and the at least one first process and the second process.

8. A device according to any one of the preceding claims, wherein: The resource is a shared data structure in memory used to exchange information between processes in a thread-safe manner, such as a ring buffer, a FIFO or a queue, or any other memory structure that enables data exchange during inter-process communication.

9. The device according to claim 8, wherein: The shared data structure includes: a ring buffer, a FIFO or a queue, or any other memory structure that enables data exchange during inter-process communication.

10. A system comprising: The device according to claim 1; a kernel driver for the device, the kernel driver being configured to integrate the device into the operating system; as well as A synchronization library is configured to provide an abstraction layer to applications performing IPC operations using the device.

11. The system according to claim 10, wherein: The synchronization library is configured to send the release notification from the second process and redirect the release notification to the notification interface of the device instead of redirecting it to the OS.

12. A method for accelerating synchronization during inter-process communication of concurrent processes executed by an operating system (OS) of a computer comprising at least one CPU core, whereby the OS maps the processes onto the at least one CPU core, the method comprising: registering and maintaining a list of at least one first process that is in a waiting state to obtain access to a contended resource shared with a second process; receiving a release notification from the second process, the release notification including the release of a lock or a semaphore, the modification of a condition variable, or the completion of a synchronization barrier; as well as A subset of the at least one first process in the waiting state is awakened after receiving the release notification from the second process.

13. A computer program comprising instructions which, when executed by a computer, cause the computer to perform the method according to claim 12.

Images