WO2024007207A1 - Mécanisme de synchronisation pour communication inter-processus - Google Patents

Mécanisme de synchronisation pour communication inter-processus Download PDF

Info

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
Application number
PCT/CN2022/104190
Other languages
English (en)
Inventor
Camille JALIER
Zhigang Huang
Jiyuan SHI
Hongbo ZHAO
Lars NOLTE
Tim TWARDZIK
Thomas Wild
Andreas Herkersdorf
Original Assignee
Huawei Technologies Co., Ltd.
Technische Universitaet Muenchen
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd., Technische Universitaet Muenchen filed Critical Huawei Technologies Co., Ltd.
Priority to PCT/CN2022/104190 priority Critical patent/WO2024007207A1/fr
Publication of WO2024007207A1 publication Critical patent/WO2024007207A1/fr

Links

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

Sont divulgués un dispositif, un système et un procédé pour accélérer la synchronisation pendant une communication inter-processus de processus simultanés exécutés par un système d'exploitation, OS, d'un ordinateur comprenant au moins un cœur de CPU, l'OS mappant les processus sur le ou les cœurs de CPU. Le dispositif comprend un module de gestion configuré pour enregistrer et maintenir une liste d'au moins un premier processus, qui est dans un état d'attente pour obtenir un accès à une ressource en conflit partagée avec un second processus; une interface de notification configurée pour recevoir une notification de libération en provenance du second processus, qui libère la ressource en conflit; et un module de réveil configuré pour demander à l'OS de réveiller un sous-ensemble du ou des premiers processus dans l'état d'attente après réception de la notification de libération en provenance du second processus.
PCT/CN2022/104190 2022-07-06 2022-07-06 Mécanisme de synchronisation pour communication inter-processus WO2024007207A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/104190 WO2024007207A1 (fr) 2022-07-06 2022-07-06 Mécanisme de synchronisation pour communication inter-processus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/104190 WO2024007207A1 (fr) 2022-07-06 2022-07-06 Mécanisme de synchronisation pour communication inter-processus

Publications (1)

Publication Number Publication Date
WO2024007207A1 true WO2024007207A1 (fr) 2024-01-11

Family

ID=89454769

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/104190 WO2024007207A1 (fr) 2022-07-06 2022-07-06 Mécanisme de synchronisation pour communication inter-processus

Country Status (1)

Country Link
WO (1) WO2024007207A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117909087A (zh) * 2024-03-20 2024-04-19 新华三技术有限公司 一种数据处理方法、装置、中央处理器及电子设备

Citations (5)

* Cited by examiner, † Cited by third party
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 (zh) * 2011-12-02 2012-07-11 华为技术有限公司 实现自适应锁的方法和装置以及多核处理器系统
CN110597640A (zh) * 2019-08-29 2019-12-20 深圳市优必选科技股份有限公司 进程间的数据传输方法、装置、终端及计算机存储介质
WO2021217529A1 (fr) * 2020-04-29 2021-11-04 华为技术有限公司 Procédé et système de communication interprocessus
CN114489823A (zh) * 2022-02-14 2022-05-13 支付宝(杭州)信息技术有限公司 用于就近唤醒cpu核心的方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
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 (zh) * 2011-12-02 2012-07-11 华为技术有限公司 实现自适应锁的方法和装置以及多核处理器系统
CN110597640A (zh) * 2019-08-29 2019-12-20 深圳市优必选科技股份有限公司 进程间的数据传输方法、装置、终端及计算机存储介质
WO2021217529A1 (fr) * 2020-04-29 2021-11-04 华为技术有限公司 Procédé et système de communication interprocessus
CN114489823A (zh) * 2022-02-14 2022-05-13 支付宝(杭州)信息技术有限公司 用于就近唤醒cpu核心的方法及装置

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117909087A (zh) * 2024-03-20 2024-04-19 新华三技术有限公司 一种数据处理方法、装置、中央处理器及电子设备

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 (ja) リクエスト管理方法及びアクセス制御システム
JPH07191944A (ja) 多重プロセッサによる多数の資源への命令におけるデッドロックを防止するためのシステムおよび方法
KR20090021208A (ko) 하드웨어 지원을 갖는 다중 프로세서 및 다중 스레드 안전 메시지 큐
CN111767159A (zh) 一种基于协程的异步系统调用系统
US20100115518A1 (en) Behavioral model based multi-threaded architecture
WO2006124750A1 (fr) Support transparent pour services de systeme d'exploitation
US9582316B2 (en) One-time initialization
WO2024007207A1 (fr) Mécanisme de synchronisation pour communication inter-processus
US7765548B2 (en) System, method and medium for using and/or providing operating system information to acquire a hybrid user/operating system lock
EP2256627A2 (fr) Files d'attente de verrous pour des données
Bruyninckx Real-time and embedded guide
Takada et al. A novel approach to multiprogrammed multiprocessor synchronization for real-time kernels
JP7346649B2 (ja) 同期制御システムおよび同期制御方法
Bhatt et al. Constant RMR solutions to reader writer synchronization
US20190042332A1 (en) Hardware locking primitive system for hardware and methods for generating same
Kluge et al. AUTOSAR OS on a message-passing multicore processor
Mejia-Alvarez et al. Interrupt handling in classic operating systems
Rothberg Interrupt handling in Linux
JP2010026575A (ja) スケジューリング方法およびスケジューリング装置並びにマルチプロセッサシステム
Wang et al. Process Synchronization

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