WO2024007207A1 - Synchronization mechanism for inter process communication - Google Patents
Synchronization mechanism for inter process communication Download PDFInfo
- Publication number
- WO2024007207A1 WO2024007207A1 PCT/CN2022/104190 CN2022104190W WO2024007207A1 WO 2024007207 A1 WO2024007207 A1 WO 2024007207A1 CN 2022104190 W CN2022104190 W CN 2022104190W WO 2024007207 A1 WO2024007207 A1 WO 2024007207A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- wake
- synchronization
- waiting state
- cpu core
- processes
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 171
- 230000008569 process Effects 0.000 title claims abstract description 154
- 238000004891 communication Methods 0.000 title claims abstract description 13
- 230000007246 mechanism Effects 0.000 title description 10
- 230000004888 barrier function Effects 0.000 claims description 5
- 238000004590 computer program Methods 0.000 claims description 3
- 230000004048 modification Effects 0.000 claims description 3
- 238000012986 modification Methods 0.000 claims description 3
- 238000012545 processing Methods 0.000 description 6
- 230000010354 integration Effects 0.000 description 5
- 230000003993 interaction Effects 0.000 description 4
- 238000013459 approach Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000000295 complement effect Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000001133 acceleration Effects 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000002618 waking effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/522—Barrier synchronisation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
Definitions
- the present disclosure relates to synchronizing processes in a computer system, for instance, in the field of computer architecture.
- the disclosure proposes a device for accelerating the synchronization 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 disclosure also proposes a system comprising the device and a method for accelerating the synchronization of concurrent processes executed by the OS.
- IPC Inter Process Communication
- the synchronization mechanism has to ensure that multiple processes are to join up or handshake to properly manage the concurrency in a multi-producer, multi-consumer relationship and that those multiple processes are, for example, respectively granted exclusive access to a resource shared by the concurrent process or threads.
- IPC is usually provided by the operating system (Kernel) as a service for the applications running on top of it.
- the performance of the IPC is becoming more and more important, as it constitutes a primary limitation/bottleneck for the scalability of the performance in multicore systems.
- Current solutions to improve the performance of the IPC mainly target either the software or the hardware.
- Software solutions are flexible, but require a few thousand of cycles for synchronization and IPC in general to perform efficiently and are only available for rich operating systems such as Linux or more widely used Posix systems.
- full hardware solutions are only available for proprietary micro and nano kernels. These solutions provide high performance, but cannot be integrated in modern rich OS due to too many integration constraints and limitations. This approach is only appropriate for simple systems like real time systems.
- this disclosure aims to accelerate the synchronization used during the IPC procedure.
- An objective of this disclosure is to offload parts of the IPC synchronization from the operating system onto a hardware accelerator.
- Another objective of this disclosure is to design the hardware accelerator such that it can be easily integrated into modern Posix operating systems such as Linux to accelerate IPC, for instance the synchronization part.
- a first aspect of this disclosure provides a device for accelerating the 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, comprising a managing module configured to register and maintain a list of at least one first process, which is in a waiting state to gain access to a contended resource shared with a second process; a notification interface configured to receive a release notification from the second process, which releases the contended resource; and a wake-up module configured to request the OS to wake up any of the at least one first process in the waiting state after receiving the release notification from the second process.
- the waiting state comprises waiting for the contended resource to be available, for example, once a lock or a semaphore is released or for a condition variable to be modified or for a synchronization barrier to be completed.
- the wake-up module is further configured to enqueue information of the subset of the at least one first process to be awakened, into a wake list of the OS and send an interrupt signal to the CPU core.
- the access to a contended resource is a write or read access.
- condition variable comprises the values full or empty in relation to the filling status of the contended resource.
- the wake-up module is further configured to: monitor a lost wake-up, wherein the lost wake-up comprises a process, which has been sent into a waiting state, but is not yet in the waiting state, when the OS is requested to wake up the process.
- the device further comprises a storage module configured to store information about the contended resource, the at least one CPU core, and the at least one first process and the second process.
- the resource is a shared data structure in memory used to exchange information in a thread safe way between processes like a ring buffer, a FIFO or queue or any other memory structure implementing data exchange during Inter Process Communication.
- the shared data structure comprises a ring buffer, a FIFO or queue or any other memory structure implementing data exchange during Inter Process Communication.
- a second aspect of this disclosure provides a system comprising the device of the first aspect; a kernel driver for the device configured to integrate the device into the operating system; and a synchronization library configured to use the device to provide an abstraction layer to an application performing IPC operations.
- 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 the OS.
- a third aspect of this disclosure provides a method for accelerating the 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, comprising the steps of registering and maintaining a list of at least one first process, which is in a waiting state to gain access to a contended resource shared with a second process; receiving a release notification from the second process, which comprises the release of a lock or a semaphore, the modification of a condition variable or the 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.
- a fourth aspect of this disclosure provides a computer program comprising instructions which, when the program is executed by a computer, cause the device of the first aspect to execute the steps of the method according to the third aspect.
- FIG. 1 shows two families of an IPC mechanism according to prior art.
- FIG. 2 shows two features required for an IPC procedure according to prior art.
- FIG. 3 shows IPC procedures according to prior art.
- FIG. 4 shows an example of a synchronization mechanism according to prior art.
- FIG. 5 shows the timeline of synchronizing the release of a contended lock shared between two threads according to an embodiment of this disclosure.
- FIG. 6 shows a device for accelerating the synchronization of concurrent processes according to an embodiment of this disclosure.
- FIG. 7 shows the interaction of a hardware accelerator with its software environment according to an embodiment of this disclosure.
- FIG. 8 shows the integration of a hardware accelerator with its computing environment according to an embodiment of this disclosure.
- FIG. 9 shows a system to accelerate the synchronization for IPC according to an embodiment of this disclosure.
- FIG. 10 shows another system for accelerating the synchronization for IPC according to an embodiment of this disclosure.
- FIG. 11 shows the interactions between a writer process and a reader process sharing a common resource according to an embodiment of this disclosure.
- FIG. 12 shows a method for accelerating the synchronization of concurrent processes according to an embodiment of this disclosure.
- FIG. 1 shows the two types of inter process communication (IPC) requiring synchronization according to prior art.
- Two processes may either share a common process region (shared memory system) or pass messages between each other (message passing system) .
- process P1 accesses its shared region to write data 1
- process P2 reads the data 2 from the shared region.
- process P1 sends a message to a kernel, which relays the message to process Ps.
- the involved processes P1 and P2 must synchronize the memory access or message passing such that process P1 is made aware of the operations carried out by process P2 and vice versa in order to avoid memory conflicts or lost messages.
- FIG. 2 shows the two features required for an IPC procedure according to prior art.
- the first feature “data transmission /sharing” consists of the exchange of data/messages in a pass messages system or the sharing of data in a shared memory system.
- the second feature “synchronization” ensures correct timing of the data/message transmissions between two processes or the sharing of data, which are stored in a common resource, by the two processes.
- FIG. 3 gives an overview of different implementations of the two basic IPC procedures, namely message passing and memory sharing, for the operating system Linux.
- FIG. 4 shows an example of a synchronization mechanism according to prior art.
- Synchronization is a critical feature, especially in parallel programming and multi-core architecture. It ensures that multiple processes join up or handshake and respectively access shared resources exclusively to properly manage the concurrency in a multi-producer, multi-consumer relationship of processes in the mentioned computer environment.
- synchronization is responsible to ensure a valid sharing of data in IPC and must therefore support critical section locking 43, which guarantees that only one process is updating a shared structure and condition variables 44, which force processes to wait until a specific condition is met.
- the synchronization can be either fully supported 42 by the OS/kernel, like the epoll Linux synchronization, or delegated to the user application (or library) 41, like a futex (short for “fast userspace mutex” ) , if there is no contention to share the data.
- a futex synchronization measures between processes are controlled. Contention arises, when more than the two processes depicted in Fig. 4. compete for a same resource.
- the shared data structure or resource may be a ring buffer 45, a FIFO or queue or any other memory structure implementing data exchange during IPC.
- the present disclosure provides a hardware-based solution to accelerate the described IPC synchronization, for example but not limited thereto, for both synchronization measures, locking a critical section to grant an exclusive access and waiting on condition variables.
- an OS implementation for a synchronization between processes and/or threads is improved by the present disclosure.
- the present innovation requires almost no SW changes for both the application and the kernel to be integrated.
- FIG. 5 shows the timeline of synchronizing the release of a contended lock shared between two threads according to an embodiment of this disclosure.
- a hardware accelerator HW ACC shown on the right section ( “With Accelerator” ) of Fig. 5 enhances the synchronization of a thread 1 with a thread 2 as is done in prior art shown on the left side ( “Software” ) of Fig. 5.
- a process or thread, named thread 2 in this example has to release a lock once an operation on a shared resource is concluded such that a waiting process ( “waiter” ) can be awakened to carry out its task with the shared resource.
- system call (commonly abbreviated to “syscall” ) , which is the programmatic way in which a computer program or process (thread 2) in this case requests a service from the kernel of the operating system on which it is executed (see encircled area in the left section of Fig. 5) .
- the requested service from the operating system consists in notifying the waiting thread 1 that the lock to the shared resource is released by thread 2.
- the operating system notifies thread 1 by sending an inter-processor interrupt IPI, because the execution of thread 1 and thread 2 is mapped to respective CPU cores. Therefore, this special type of interrupt, by which one processor may interrupt another processor in a multiprocessor system, if the interrupting processor requires action from the other processor, is used. Both threads, however, may also be mapped onto one CPU core.
- a hardware accelerator HW ACC enhances the synchronization as performed in prior art by accelerating a wake sequence, which is initiated by Thread 2 carrying out above-described syscall ( “Release lock with waiter” , encircled area in left section of Fig. 5) to the operating system.
- the syscall or release notification is redirected to the hardware accelerator by which measure the waker thread (thread 2) is prevented to call the kernel through the syscall for the notification and is directed to initiate a wake-up sequence by only calling the synchronization library of thread 2.
- this redirection thread 2 can offload the wake-up sequence/process using the hardware accelerator and is relieved from the duty of waking up a waiting thread.
- FIG. 6 shows a device 60 for accelerating the synchronization of concurrent processes according to an embodiment of this disclosure.
- the device is suitable for accelerating the synchronization during 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.
- OS operating system
- the device comprises a managing module 61 configured to register and maintain a list of at least one first process, which is in a waiting state to gain access to a contended resource shared with a second process; a notification interface 62 configured to receive a release notification from the second process, which releases the contended 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 the waiting state after receiving the release notification from the second process.
- a managing module 61 configured to register and maintain a list of at least one first process, which is in a waiting state to gain access to a contended resource shared with a second process
- a notification interface 62 configured to receive a release notification from the second process, which releases the contended resource
- a wake-up module 63 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.
- FIG. 7 shows the interaction of a hardware accelerator 60 with its parallelized computing environment represented by concurrent Process A and Process B according to an embodiment of this disclosure.
- the present disclosure may accelerate a Linux futex (short for “fast userspace mutex” ) , by which synchronization measures between Process A and Process B are controlled according to the state of the art.
- a futex is used to implement high performance IPC in parallel programming. It is the building block for higher-level locking abstractions such as semaphores and Posix mutexes (short for “mutual exclusions” ) or condition variables.
- the futex is usually abstracted through a system library such as the Native Posix Thread Library (NPTL) .
- NPTL Native Posix Thread Library
- a futex consists of a wait queue in the kernelspace 72 that is attached to an atomic integer in userspace 71. It basically functions as a counter in shared memory that can be incremented and decremented atomically, which is a computing expression to describe the performing of steps one at a time. Processes can then wait for the value to become positive before accessing the shared resource, for example. Processes or threads in prior art usually operate on the atomic integer entirely in userspace 71 by using atomic operations to avoid interfering with one another as just mentioned, when there is only a process A exchanging messages or sharing memory space with a process B (uncontended case) .
- Processes or threads only resort to relatively expensive syscalls involving kernel operations 74 (outside userspace) to request operations on the wait queue, if the kernel needs to be involved to arbitrate between a number of processes A competing for access to a resource about to be released by a process B (contended case) .
- the kernel will then wake up some of the waiting processes A and/or will put a current process B on the wait queue, if there are also a number of processes B competing for a same resource.
- uncontended and contended cases are supported by the present disclosure.
- the hardware accelerator 60 may support userspace 71 synchronization via userspace memory.
- the hardware accelerator 60 accelerates the synchronization between a number of processes A and a number of processes B compared to the method applied in prior art and described above.
- the hardware accelerator 60 is configured to receive a release notification of a blocked shared resource as is shown by the arrow “Wake up” in Fig. 7, wherein process A releases the shared resource after having accessed and/or modified it. Due to this feature a syscall to request kernel operations 74 on the wait queue in order to wake up waiting processes is not required anymore, because the release notification is redirected (see arrow “Wake up” in direction to “HW accelerator” in Fig. 7) to the hardware accelerator device instead of to the kernel/OS. This execution path via the hard accelerator 100 reduces the wake-up cost by 90%.
- the hardware accelerator according to the present disclosure provides a new mechanism to awake processes, which are waiting based on a futex, by staying in user mode/space 71 and preventing the overhead of a syscall, which involves resource-intensive kernel operations.
- the hardware accelerator according to the present disclosure may be integrated in a multicore and manycore system by configuring it such that it is interacting with CPU cores, on which to-be-synchronized processes are executed and which manage wait/wake notifications to the hardware accelerator 60, with the memory, which stores user/kernel structures that are mainly used by the software but also accessed by the hardware accelerator and with the interrupt controller, which interrupts the CPU cores and triggers the kernel related interrupt handler.
- FIG. 8 shows an exemplary integration of a hardware accelerator based on Fig. 6 with its computing environment.
- the hardware accelerator of this embodiment may comprise the following architecture to carry out above-described interacting with its hardware environment such as CPU cores, memory and interrupt controller.
- the managing module 81 may be configured to operate as a Futex Manager by registering and maintaining a list of threads/processes, which are waiting on a futex.
- the notification interface 82 may be configured to operate as a Config interface by handling CPU core configuration and notifications.
- the wake-up module 83 may be configured to operate as a wake-up engine, which wakes up a thread/process, which is waiting on a futex after receiving a notification that the futex has been released.
- the exemplary implementation of a hardware accelerator according to Fig. 8 may further comprise an internal storage, which stores futex, CPU core and thread/process related information.
- the internal storage may be distributed in a number of storage modules as shown in Fig. 8 or maybe separated in storage areas, which are respectively integrated in the managing module, notification interface and wake-up module of Fig. 6 to provide their associated module/interface with necessary information to carry out their tasks as described above in the paragraph relating to Fig. 8.
- the particular way of providing storage in a suitable way lies within the general knowledge of the skilled, once the tasks to be carried out by the managing module 61, notification interface 62 and wake-up module 63 of Fig. 6 are known.
- FIG. 9 shows a system 90 to accelerate the synchronization for IPC according to an embodiment of this disclosure.
- the system comprises the hardware accelerator 60 of Fig. 6, a kernel driver 92 for the device configured to integrate the device into the operating system; and a synchronization library 91 for the device configured to provide an abstraction layer to an application performing library calls.
- FIG. 10 shows another system for accelerating the synchronization for IPC based on the system 90 of Fig. 9.
- the acceleration of the IPC mechanism may be implemented to be transparent to an existing application and may comprise the three components of Fig. 9, which are configured in the following way:
- a modified synchronization library 91 to provide an abstraction layer to the application for a seamless integration to the final application
- a Hardware accelerator device 60 that communicates with the CPU cores to offload the IPC synchronization from the CPU cores and operating system
- a queue or a ring buffer is a simple data structure that implements a FIFO (First-In-First-Out) ordering protocol, which guarantees that messages by the same sender are delivered in the order that they were sent.
- the ring buffer is usually defined with a read pointer, a write pointer and a capacity. Those pointers are used to define where to read or write and if the queue is full or empty. They are shared between all readers and writers of the queue. Manipulating the pointers requires an exclusive access to ensure two or more processes cannot write the same slot of the queue or corrupt the queue. The exclusive access can be implemented with futex.
- FIG. 11 shows the interactions between a writer process (or enqueue process) and a reader process (or dequeue process) sharing a common resource in a contended case according to an embodiment of this disclosure.
- the depicted scenario considers contention for both process types, namely a contended enqueue process and a contended dequeue process, which are shown on the left and right side of Fig. 11.
- contention cases for the depicted queue are:
- the queue is full 2’ as indicated by the dequeue process 4’.
- the enqueue process cannot enqueue an element despite a released lock and needs to wait for a dequeue process to free a slot 3.
- the queue is empty 2’ as indicated by the enqueuer process 4’, the dequeuer process cannot dequeue an element and needs to wait for a enqueuer process to push an element 3.
- FIG. 12 shows a method 120 for accelerating the synchronization of concurrent processes according to an embodiment of this disclosure,
- the method is suitable for accelerating the synchronization during 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, comprising the steps of registering and maintaining 121 a list of at least one first process, which is in a waiting state to gain access to a contended resource shared with a second process; receiving 122 a release notification from the second process, which comprises the release of a lock or a semaphore, the modification of a condition variable or the completion of a synchronization barrier; and waking-up 123 a subset of the at least one first process in the waiting state after receiving the release notification from the second process.
- the devices described in the above may comprise a processor or processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the device described herein.
- the processing circuitry may comprise hardware and/or the processing circuitry may be controlled by software.
- the hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry.
- the digital circuitry may comprise components such as application-specific integrated circuits (ASICs) , field-programmable arrays (FPGAs) , digital signal processors (DSPs) , or multi-purpose processors.
- the device may further comprise memory circuitry, which stores one or more instruction (s) that can be executed by the processor or by the processing circuitry, in particular under control of the software.
- the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the device to be performed.
- the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors.
- the non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the device to perform, conduct or initiate the operations or methods described herein.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multi Processors (AREA)
Abstract
A device, system and method is disclosed for accelerating the 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 device comprises a managing module configured to register and maintain a list of at least one first process, which is in a waiting state to gain access to a contended resource shared with a second process; a notification interface configured to receive a release notification from the second process, which releases the contended 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
The present disclosure relates to synchronizing processes in a computer system, for instance, in the field of computer architecture. The disclosure proposes a device for accelerating the synchronization 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 disclosure also proposes a system comprising the device and a method for accelerating the synchronization of concurrent processes executed by the OS.
In modern systems-on-a-chip, an increasing number of CPU cores and accelerators are interconnected. To benefit from the performance and the modularity of multicore systems, modern applications are designed with parallel (or concurrent) , multiple processes/threads, which are interacting and co-operating. Those applications running on such systems need to exchange information/messages between the different computing units. This mechanism is usually called Inter Process Communication (IPC) . IPC is based on a Shared Memory or a Message Passing model with a synchronization mechanism, in order to not only exchange data or messages between the processes or threads, but also to do it in a timely, synchronized and reliable fashion. To this end, the synchronization mechanism has to ensure that multiple processes are to join up or handshake to properly manage the concurrency in a multi-producer, multi-consumer relationship and that those multiple processes are, for example, respectively granted exclusive access to a resource shared by the concurrent process or threads. IPC is usually provided by the operating system (Kernel) as a service for the applications running on top of it.
The performance of the IPC is becoming more and more important, as it constitutes a primary limitation/bottleneck for the scalability of the performance in multicore systems. Current solutions to improve the performance of the IPC mainly target either the software or the hardware. Software solutions are flexible, but require a few thousand of cycles for synchronization and IPC in general to perform efficiently and are only available for rich operating systems such as Linux or more widely used Posix systems. On the other hand, full hardware solutions are only available for proprietary micro and nano kernels. These solutions provide high performance, but cannot be integrated in modern rich OS due to too many integration constraints and limitations. This approach is only appropriate for simple systems like real time systems.
There is no existing solution to accelerate the IPC by using hardware for Posix-compliant systems such as Linux with a generic approach to be easily integrated into existing systems. The software legacy of a complex OS requires a solution with almost no software changes to minimize the impact on existing software ecosystems.
SUMMARY
In view of the above, this disclosure aims to accelerate the synchronization used during the IPC procedure. An objective of this disclosure is to offload parts of the IPC synchronization from the operating system onto a hardware accelerator. Another objective of this disclosure is to design the hardware accelerator such that it can be easily integrated into modern Posix operating systems such as Linux to accelerate IPC, for instance the synchronization part.
These and other objectives are achieved by the solution of this disclosure as described in the independent claims. Advantageous implementations are further defined in the dependent claims.
A first aspect of this disclosure provides a device for accelerating the 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, comprising a managing module configured to register and maintain a list of at least one first process, which is in a waiting state to gain access to a contended resource shared with a second process; a notification interface configured to receive a release notification from the second process, which releases the contended resource; and a wake-up module configured to request the OS to wake up any of the at least one first process in the waiting state after receiving the release notification from the second process.
In an implementation form of the first aspect, the waiting state comprises waiting for the contended resource to be available, for example, once a lock or a semaphore is released or for a condition variable to be modified or for a synchronization barrier to be completed.
In an implementation form 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 awakened, into a wake list of the OS and send an interrupt signal to the CPU core.
In an implementation form of the first aspect, the access to a contended resource is a write or read access.
In an implementation form of the first aspect, the condition variable comprises the values full or empty in relation to the filling status of the contended resource.
In an implementation form of the first aspect, the wake-up module is further configured to: monitor a lost wake-up, wherein the lost wake-up comprises a process, which has been sent into a waiting state, but is not yet in the waiting state, when the OS is requested to wake up the process.
In an implementation form of the first aspect, the device further comprises a storage module configured to store information about the contended resource, the at least one CPU core, and the at least one first process and the second process.
In an implementation form of the first aspect, the resource is a shared data structure in memory used to exchange information in a thread safe way between processes like a ring buffer, a FIFO or queue or any other memory structure implementing data exchange during Inter Process Communication.
In an implementation form of the first aspect, the shared data structure comprises a ring buffer, a FIFO or queue or any other memory structure implementing data exchange during Inter Process Communication.
A second aspect of this disclosure provides a system comprising the device of the first aspect; a kernel driver for the device configured to integrate the device into the operating system; and a synchronization library configured to use the device to provide an abstraction layer to an application performing IPC operations.
In an implementation form of the second aspect, 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 the OS.
A third aspect of this disclosure provides a method for accelerating the 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, comprising the steps of registering and maintaining a list of at least one first process, which is in a waiting state to gain access to a contended resource shared with a second process; receiving a release notification from the second process, which comprises the release of a lock or a semaphore, the modification of a condition variable or the 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.
A fourth aspect of this disclosure provides a computer program comprising instructions which, when the program is executed by a computer, cause the device of the first aspect to execute the steps of the method according to the third aspect.
It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.
BRIEF DESCRIPTION OF DRAWINGS
The above described aspects and implementation forms will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which
FIG. 1 shows two families of an IPC mechanism according to prior art.
FIG. 2 shows two features required for an IPC procedure according to prior art.
FIG. 3 shows IPC procedures according to prior art.
FIG. 4 shows an example of a synchronization mechanism according to prior art.
FIG. 5 shows the timeline of synchronizing the release of a contended lock shared between two threads according to an embodiment of this disclosure.
FIG. 6 shows a device for accelerating the synchronization of concurrent processes according to an embodiment of this disclosure.
FIG. 7 shows the interaction of a hardware accelerator with its software environment according to an embodiment of this disclosure.
FIG. 8 shows the integration of a hardware accelerator with its computing environment according to an embodiment of this disclosure.
FIG. 9 shows a system to accelerate the synchronization for IPC according to an embodiment of this disclosure.
FIG. 10 shows another system for accelerating the synchronization for IPC according to an embodiment of this disclosure.
FIG. 11 shows the interactions between a writer process and a reader process sharing a common resource according to an embodiment of this disclosure.
FIG. 12 shows a method for accelerating the synchronization of concurrent processes according to an embodiment of this disclosure.
DETAILED DESCRIPTION OF EMBODIMENTS
FIG. 1 shows the two types of inter process communication (IPC) requiring synchronization according to prior art. Two processes may either share a common process region (shared memory system) or pass messages between each other (message passing system) . In a shared memory system, for example, process P1 accesses its shared region to write data 1, while process P2 reads the data 2 from the shared region. In a message passing system, for example, process P1 sends a message to a kernel, which relays the message to process Ps. In both cases the involved processes P1 and P2 must synchronize the memory access or message passing such that process P1 is made aware of the operations carried out by process P2 and vice versa in order to avoid memory conflicts or lost messages.
FIG. 2 shows the two features required for an IPC procedure according to prior art. The first feature “data transmission /sharing” consists of the exchange of data/messages in a pass messages system or the sharing of data in a shared memory system. The second feature “synchronization” ensures correct timing of the data/message transmissions between two processes or the sharing of data, which are stored in a common resource, by the two processes.
FIG. 3 gives an overview of different implementations of the two basic IPC procedures, namely message passing and memory sharing, for the operating system Linux.
FIG. 4 shows an example of a synchronization mechanism according to prior art. Synchronization is a critical feature, especially in parallel programming and multi-core architecture. It ensures that multiple processes join up or handshake and respectively access shared resources exclusively to properly manage the concurrency in a multi-producer, multi-consumer relationship of processes in the mentioned computer environment. Particularly, synchronization is responsible to ensure a valid sharing of data in IPC and must therefore support critical section locking 43, which guarantees that only one process is updating a shared structure and condition variables 44, which force processes to wait until a specific condition is met.
The synchronization can be either fully supported 42 by the OS/kernel, like the epoll Linux synchronization, or delegated to the user application (or library) 41, like a futex (short for “fast userspace mutex” ) , if there is no contention to share the data. By the use of a futex synchronization measures between processes are controlled. Contention arises, when more than the two processes depicted in Fig. 4. compete for a same resource. The shared data structure or resource may be a ring buffer 45, a FIFO or queue or any other memory structure implementing data exchange during IPC.
The present disclosure provides a hardware-based solution to accelerate the described IPC synchronization, for example but not limited thereto, for both synchronization measures, locking a critical section to grant an exclusive access and waiting on condition variables. Moreover, an OS implementation for a synchronization between processes and/or threads is improved by the present disclosure. Further, the present innovation requires almost no SW changes for both the application and the kernel to be integrated.
FIG. 5 shows the timeline of synchronizing the release of a contended lock shared between two threads according to an embodiment of this disclosure. A hardware accelerator HW ACC shown on the right section ( “With Accelerator” ) of Fig. 5 enhances the synchronization of a thread 1 with a thread 2 as is done in prior art shown on the left side ( “Software” ) of Fig. 5. According to prior art, a process or thread, named thread 2 in this example, has to release a lock once an operation on a shared resource is concluded such that a waiting process ( “waiter” ) can be awakened to carry out its task with the shared resource. It is doing so by performing a system call (commonly abbreviated to “syscall” ) , which is the programmatic way in which a computer program or process (thread 2) in this case requests a service from the kernel of the operating system on which it is executed (see encircled area in the left section of Fig. 5) . The requested service from the operating system consists in notifying the waiting thread 1 that the lock to the shared resource is released by thread 2. In this example in prior art, the operating system notifies thread 1 by sending an inter-processor interrupt IPI, because the execution of thread 1 and thread 2 is mapped to respective CPU cores. Therefore, this special type of interrupt, by which one processor may interrupt another processor in a multiprocessor system, if the interrupting processor requires action from the other processor, is used. Both threads, however, may also be mapped onto one CPU core.
This synchronization scheme according to prior art has the disadvantage that a syscall is costly in terms of execution time, particularly if more than one thread 1 is waiting for gaining access to the shared resource. According to an embodiment of the present disclosure shown in Fig. 5 a hardware accelerator HW ACC enhances the synchronization as performed in prior art by accelerating a wake sequence, which is initiated by Thread 2 carrying out above-described syscall ( “Release lock with waiter” , encircled area in left section of Fig. 5) to the operating system. At first the syscall or release notification is redirected to the hardware accelerator by which measure the waker thread (thread 2) is prevented to call the kernel through the syscall for the notification and is directed to initiate a wake-up sequence by only calling the synchronization library of thread 2. As a result of this redirection thread 2 can offload the wake-up sequence/process using the hardware accelerator and is relieved from the duty of waking up a waiting thread.
FIG. 6 shows a device 60 for accelerating the synchronization of concurrent processes according to an embodiment of this disclosure. In particular, the device is suitable for accelerating the synchronization during 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 comprises a managing module 61 configured to register and maintain a list of at least one first process, which is in a waiting state to gain access to a contended resource shared with a second process; a notification interface 62 configured to receive a release notification from the second process, which releases the contended 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 the waiting state after receiving the release notification from the second process.
FIG. 7 shows the interaction of a hardware accelerator 60 with its parallelized computing environment represented by concurrent Process A and Process B according to an embodiment of this disclosure. The present disclosure may accelerate a Linux futex (short for “fast userspace mutex” ) , by which synchronization measures between Process A and Process B are controlled according to the state of the art. Therein, a futex is used to implement high performance IPC in parallel programming. It is the building block for higher-level locking abstractions such as semaphores and Posix mutexes (short for “mutual exclusions” ) or condition variables. The futex is usually abstracted through a system library such as the Native Posix Thread Library (NPTL) .
A futex consists of a wait queue in the kernelspace 72 that is attached to an atomic integer in userspace 71. It basically functions as a counter in shared memory that can be incremented and decremented atomically, which is a computing expression to describe the performing of steps one at a time. Processes can then wait for the value to become positive before accessing the shared resource, for example. Processes or threads in prior art usually operate on the atomic integer entirely in userspace 71 by using atomic operations to avoid interfering with one another as just mentioned, when there is only a process A exchanging messages or sharing memory space with a process B (uncontended case) . Processes or threads only resort to relatively expensive syscalls involving kernel operations 74 (outside userspace) to request operations on the wait queue, if the kernel needs to be involved to arbitrate between a number of processes A competing for access to a resource about to be released by a process B (contended case) . The kernel will then wake up some of the waiting processes A and/or will put a current process B on the wait queue, if there are also a number of processes B competing for a same resource.
According to the embodiment shown in Fig. 7, uncontended and contended cases are supported by the present disclosure. In an uncontended case, where synchronization is carried out in userspace 71, processes do not need to communicate with the hardware accelerator 60 of the present disclosure. In this case, the hardware accelerator 60 may support userspace 71 synchronization via userspace memory.
In a contended case, where synchronization is carried out in the kernel 72, the hardware accelerator 60 according to the present disclosure accelerates the synchronization between a number of processes A and a number of processes B compared to the method applied in prior art and described above. To this end, the hardware accelerator 60 is configured to receive a release notification of a blocked shared resource as is shown by the arrow “Wake up” in Fig. 7, wherein process A releases the shared resource after having accessed and/or modified it. Due to this feature a syscall to request kernel operations 74 on the wait queue in order to wake up waiting processes is not required anymore, because the release notification is redirected (see arrow “Wake up” in direction to “HW accelerator” in Fig. 7) to the hardware accelerator device instead of to the kernel/OS. This execution path via the hard accelerator 100 reduces the wake-up cost by 90%.
The hardware accelerator according to the present disclosure provides a new mechanism to awake processes, which are waiting based on a futex, by staying in user mode/space 71 and preventing the overhead of a syscall, which involves resource-intensive kernel operations.
The hardware accelerator according to the present disclosure may be integrated in a multicore and manycore system by configuring it such that it is interacting with CPU cores, on which to-be-synchronized processes are executed and which manage wait/wake notifications to the hardware accelerator 60, with the memory, which stores user/kernel structures that are mainly used by the software but also accessed by the hardware accelerator and with the interrupt controller, which interrupts the CPU cores and triggers the kernel related interrupt handler.
FIG. 8 shows an exemplary integration of a hardware accelerator based on Fig. 6 with its computing environment. As an example, but not limited to, the hardware accelerator of this embodiment may comprise the following architecture to carry out above-described interacting with its hardware environment such as CPU cores, memory and interrupt controller. The managing module 81 may be configured to operate as a Futex Manager by registering and maintaining a list of threads/processes, which are waiting on a futex. The notification interface 82 may be configured to operate as a Config interface by handling CPU core configuration and notifications. The wake-up module 83 may be configured to operate as a wake-up engine, which wakes up a thread/process, which is waiting on a futex after receiving a notification that the futex has been released. The exemplary implementation of a hardware accelerator according to Fig. 8 may further comprise an internal storage, which stores futex, CPU core and thread/process related information. However, the internal storage may be distributed in a number of storage modules as shown in Fig. 8 or maybe separated in storage areas, which are respectively integrated in the managing module, notification interface and wake-up module of Fig. 6 to provide their associated module/interface with necessary information to carry out their tasks as described above in the paragraph relating to Fig. 8. The particular way of providing storage in a suitable way, however, lies within the general knowledge of the skilled, once the tasks to be carried out by the managing module 61, notification interface 62 and wake-up module 63 of Fig. 6 are known.
FIG. 9 shows a system 90 to accelerate the synchronization for IPC according to an embodiment of this disclosure. The system comprises the hardware accelerator 60 of Fig. 6, a kernel driver 92 for the device configured to integrate the device into the operating system; and a synchronization library 91 for the device configured to provide an abstraction layer to an application performing library calls.
FIG. 10 shows another system for accelerating the synchronization for IPC based on the system 90 of Fig. 9. In this embodiment the acceleration of the IPC mechanism may be implemented to be transparent to an existing application and may comprise the three components of Fig. 9, which are configured in the following way:
· A modified synchronization library 91 to provide an abstraction layer to the application for a seamless integration to the final application
· A kernel driver 92 for the accelerator system to provide a seamless integration into the operating system
· A Hardware accelerator device 60 that communicates with the CPU cores to offload the IPC synchronization from the CPU cores and operating system
For example, above described embodiments may be used to accelerate a well-known IPC structure called a queue or a ring buffer 45. A queue or a ring buffer is a simple data structure that implements a FIFO (First-In-First-Out) ordering protocol, which guarantees that messages by the same sender are delivered in the order that they were sent. The ring buffer is usually defined with a read pointer, a write pointer and a capacity. Those pointers are used to define where to read or write and if the queue is full or empty. They are shared between all readers and writers of the queue. Manipulating the pointers requires an exclusive access to ensure two or more processes cannot write the same slot of the queue or corrupt the queue. The exclusive access can be implemented with futex.
The example below shows a simplified enqueue/dequeue manoever based on pthreads (posix threads) implemented in Linux, which is accelerated by the embodiments
described above.
FIG. 11 shows the interactions between a writer process (or enqueue process) and a reader process (or dequeue process) sharing a common resource in a contended case according to an embodiment of this disclosure. The depicted scenario considers contention for both process types, namely a contended enqueue process and a contended dequeue process, which are shown on the left and right side of Fig. 11.
The contention cases for the depicted queue are:
· The queue is already locked 1’ for a process, because its complement process it is interacting with (on the opposite side of Fig. 11) is writing or reading 3. The pointer values are under update. The process needs to wait for the lock being released 5’, before it can continue its complement operation.
· The queue is full 2’ as indicated by the dequeue process 4’. The enqueue process cannot enqueue an element despite a released lock and needs to wait for a dequeue process to free a slot 3.
· The queue is empty 2’ as indicated by the enqueuer process 4’, the dequeuer process cannot dequeue an element and needs to wait for a enqueuer process to push an element 3.
In these cases of contention, notifications have to be sent when releasing a lock, pushing a new element or freeing a slot in the queue. All those notifications depicted in dashed line in Fig. 11 are accelerated by the HW accelerator.
FIG. 12 shows a method 120 for accelerating the synchronization of concurrent processes according to an embodiment of this disclosure, In particular, the method is suitable for accelerating the synchronization during 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, comprising the steps of registering and maintaining 121 a list of at least one first process, which is in a waiting state to gain access to a contended resource shared with a second process; receiving 122 a release notification from the second process, which comprises the release of a lock or a semaphore, the modification of a condition variable or the completion of a synchronization barrier; and waking-up 123 a subset of the at least one first process in the waiting state after receiving the release notification from the second process.
The devices described in the above may comprise a processor or processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the device described herein. The processing circuitry may comprise hardware and/or the processing circuitry may be controlled by software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs) , field-programmable arrays (FPGAs) , digital signal processors (DSPs) , or multi-purpose processors. The device may further comprise memory circuitry, which stores one or more instruction (s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the device to be performed. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the device to perform, conduct or initiate the operations or methods described herein.
The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed matter, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.
Claims (13)
- A device for accelerating the 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, comprising:a managing module configured to register and maintain a list of at least one first process, which is in a waiting state to gain access to a contended resource shared with a second process;a notification interface configured to receive a release notification from the second process, which releases the contended resource; anda 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.
- The device according to claim 1, wherein the waiting state comprises waiting for the contended resource to be available once a lock or a semaphore is released or for a condition variable to be modified or for a synchronization barrier to be completed.
- The device according to any one of the claims above, wherein the wake-up module is further configured to enqueue information of the subset of the at least one first process to be awakened into a wake list of the OS and send an interrupt signal to the CPU core.
- The device according to any one of the claims above, wherein the access to a contended resource is a write or read access.
- The device according to any one of the claims above, wherein the condition variable comprises the values full or empty in relation to the filling status of the contended resource.
- The device according to any one of the claims above, wherein the wake-up module is further configured to:monitor a lost wake-up, wherein the lost wake-up comprises a process, which has been sent into a waiting state, but is not yet in the waiting state, when the OS is requested to wake up the process.
- The device according to any one of the claims above,wherein the device further comprises a storage module configured to store information about the contended resource, the at least one CPU core, and the at least one first process and the second process.
- The device according to any of the claims above, wherein the resource is a shared data structure in memory used to exchange information in a thread safe way between processes like a ring buffer, a FIFO or queue or any other memory structure implementing data exchange during Inter Process Communication.
- The device according to claim 8 wherein the shared data structure comprises a ring buffer, a FIFO or queue or any other memory structure implementing data exchange during Inter Process Communication.
- A system, comprising:the device of claim 1;a kernel driver for the device configured to integrate the device into the operating system; anda synchronization library configured to use the device to provide an abstraction layer to an application performing IPC operations.
- The system according to claim 10, whereinthe 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 to the OS.
- A method for accelerating the 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, comprising:registering and maintaining a list of at least one first process, which is in a waiting state to gain access to a contended resource shared with a second process;receiving a release notification from the second process, which comprises the release of a lock or a semaphore, the modification of a condition variable or the completion of a synchronization barrier; andwaking-up a subset of the at least one first process in the waiting state after receiving the release notification from the second process.
- A computer program comprising instructions which, when the program is executed by a computer, cause the computer to perform the method according to claim 12.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2022/104190 WO2024007207A1 (en) | 2022-07-06 | 2022-07-06 | Synchronization mechanism for inter process communication |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2022/104190 WO2024007207A1 (en) | 2022-07-06 | 2022-07-06 | Synchronization mechanism for inter process communication |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2024007207A1 true WO2024007207A1 (en) | 2024-01-11 |
Family
ID=89454769
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2022/104190 WO2024007207A1 (en) | 2022-07-06 | 2022-07-06 | Synchronization mechanism for inter process communication |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO2024007207A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117909087A (en) * | 2024-03-20 | 2024-04-19 | 新华三技术有限公司 | Data processing method and device, central processing unit and electronic equipment |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080263545A1 (en) * | 2007-04-23 | 2008-10-23 | Hewlett-Packard Development Company, L.P. | Signal delivery to a process in a process group |
CN102566979A (en) * | 2011-12-02 | 2012-07-11 | 华为技术有限公司 | Method, device and multi-core processor system for realizing self-adaptive lock |
CN110597640A (en) * | 2019-08-29 | 2019-12-20 | 深圳市优必选科技股份有限公司 | Inter-process data transmission method and device, terminal and computer storage medium |
WO2021217529A1 (en) * | 2020-04-29 | 2021-11-04 | 华为技术有限公司 | Method and system for inter-process communication |
CN114489823A (en) * | 2022-02-14 | 2022-05-13 | 支付宝(杭州)信息技术有限公司 | Method and device for waking up CPU core nearby |
-
2022
- 2022-07-06 WO PCT/CN2022/104190 patent/WO2024007207A1/en unknown
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080263545A1 (en) * | 2007-04-23 | 2008-10-23 | Hewlett-Packard Development Company, L.P. | Signal delivery to a process in a process group |
CN102566979A (en) * | 2011-12-02 | 2012-07-11 | 华为技术有限公司 | Method, device and multi-core processor system for realizing self-adaptive lock |
CN110597640A (en) * | 2019-08-29 | 2019-12-20 | 深圳市优必选科技股份有限公司 | Inter-process data transmission method and device, terminal and computer storage medium |
WO2021217529A1 (en) * | 2020-04-29 | 2021-11-04 | 华为技术有限公司 | Method and system for inter-process communication |
CN114489823A (en) * | 2022-02-14 | 2022-05-13 | 支付宝(杭州)信息技术有限公司 | Method and device for waking up CPU core nearby |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117909087A (en) * | 2024-03-20 | 2024-04-19 | 新华三技术有限公司 | Data processing method and device, central processing unit and electronic equipment |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7962923B2 (en) | System and method for generating a lock-free dual queue | |
US8239867B2 (en) | Method and apparatus for implementing atomic FIFO | |
US8161481B2 (en) | Operating system providing a mutual exclusion mechanism | |
US6934950B1 (en) | Thread dispatcher for multi-threaded communication library | |
US8572626B2 (en) | Symmetric multi-processor system | |
JPH03161859A (en) | Request control method and access control system | |
JPH07191944A (en) | System and method for prevention of deadlock in instruction to many resources by multiporcessor | |
KR20090021208A (en) | Multi processor and multi thread safe message queue with hardware assistance | |
CN111767159A (en) | Asynchronous system calling system based on coroutine | |
US9582316B2 (en) | One-time initialization | |
US20100115518A1 (en) | Behavioral model based multi-threaded architecture | |
WO2006124750A1 (en) | Transparent support for operating system services | |
WO2024007207A1 (en) | Synchronization mechanism for inter process communication | |
US7765548B2 (en) | System, method and medium for using and/or providing operating system information to acquire a hybrid user/operating system lock | |
EP2256627B1 (en) | Queuing for locks on data | |
US8578380B1 (en) | Program concurrency control using condition variables | |
Takada et al. | A novel approach to multiprogrammed multiprocessor synchronization for real-time kernels | |
JP7346649B2 (en) | Synchronous control system and method | |
Bhatt et al. | Constant RMR solutions to reader writer synchronization | |
Rheindt et al. | CaCAO: complex and compositional atomic operations for NoC-based manycore platforms | |
US20190042332A1 (en) | Hardware locking primitive system for hardware and methods for generating same | |
Rothberg | Interrupt handling in Linux | |
Kluge et al. | AUTOSAR OS on a message-passing multicore processor | |
Mejia-Alvarez et al. | Interrupt handling in classic operating systems | |
JP2010026575A (en) | Scheduling method, scheduling device, and multiprocessor system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 22949793 Country of ref document: EP Kind code of ref document: A1 |