Method and apparatus for managing kernel services in a multi-core system

Abstract

The present disclosure provides a method and apparatus for managing kernel services in a multi-core system. Embodiments of the present application provide a method for managing kernel services in a multi-core system. The method includes: configuring a lock for a kernel and configuring an object-specific lock for a shared resource of the kernel; and using the object-specific lock, processing IPC services for different shared resources on multiple cores of the multi-core system in parallel.

Description

Technical Field

[0001] Embodiments of the present application relate to a real-time operating system, and more particularly, to a method and apparatus for managing kernel services in a multi-core system. Background Art

[0002] Generally, symmetric multiprocessing (SMP) systems are an important form of processing on multi-core systems. SMP systems process multiple tasks using multi-core systems that are connected to a single shared memory, have access to all input and output devices, and are controlled by a single operating system instance that treats multiple cores of the multi-core system equally. Each core of the multi-core system runs independently of each other and executes different programs by processing different data sets. The operating system includes a kernel that implements core kernel services such as inter-process communication (IPC) and critical section / resource management.

[0003] A task running on one of the multiple cores can send any message to another task running on the same core or a different core. Message queues (mailboxes), events, signals are IPCs used for synchronous and asynchronous communication between tasks. Message queues and events are examples of synchronous IPC, while signal handling is an example of asynchronous function calls. Global variables and buffers that can be accessed and modified from different threads or interrupt service routines (ISRs) are kernel resources shared between multiple tasks. When a first task is accessing a shared kernel resource, a second task should not be allowed to modify the shared kernel resource that the first task is accessing. If a second task accesses a shared kernel resource that is being read by a first task, the first task will read inconsistent contents of the shared kernel resource.

[0004] Thus, a common kernel lock is used to protect shared kernel resources and kernel service object instances. Kernel service object instances may be, for example, mutexes, semaphores, events, message queues, etc. associated with core kernel services across multiple cores of a multi-core system. However, the use of a common kernel lock may affect interrupt latency, thereby affecting the real-time response of a multi-core system. In addition, even if a task running on an IPC does not require any kernel scheduling, conventional methods still employ a common kernel lock, thereby increasing latency.

[0005] The above information is presented only as background information to help readers understand the present disclosure. Applicants have not made any determination or assertion as to whether any of the above content is applicable to the prior art related to the present application. Summary of the invention

[0006] The main purpose of the embodiments of the present application is to provide a method and device for managing kernel services in a multi-core system.

[0007] Another object of an embodiment of the present application is to configure a lock for a kernel.

[0008] Another object of embodiments of the present application is to configure object-specific locks for shared resources of a kernel.

[0009] Another object of an embodiment of the present application is to use object-specific locks to parallelize IPC services for different shared resources on multiple cores of a multi-core system.

[0010] Therefore, an embodiment of the present application provides a method for managing kernel services in a multi-core system. The method includes: configuring a lock for the kernel and configuring an object-specific lock for a shared resource of the kernel; and using the object-specific lock, processing IPC services for different shared resources on multiple cores of the multi-core system in parallel.

[0011] Therefore, an embodiment of the present application provides an apparatus for managing kernel services in a multi-core system. The apparatus includes: a memory, a multi-core processor including multiple cores, and an operating system (OS) running on the multi-core processor, wherein the OS includes a kernel and a kernel resource engine connected to the multi-core processor and the memory. The kernel resource engine is configured to: configure locks for the kernel, configure object-specific locks for the shared resources of the kernel; and use the object-specific locks to process IPC services for different shared resources on multiple cores of the multi-core system in parallel.

[0012] When considered in conjunction with the following description and the accompanying drawings, these and other aspects of the embodiments of the present application will be better appreciated and understood. However, it should be understood that although the following description indicates preferred embodiments and a large number of specific details thereof, they are given by way of example and not limitation. Without departing from the spirit of the present invention, many changes and modifications can be made within the scope of the embodiments of the present application, and the embodiments of the present application include all such modifications. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The present disclosure is shown in the accompanying drawings, and the same reference numerals indicate the same components in all drawings. The embodiments of the present application will be better understood through the following description with reference to the accompanying drawings, in which:

[0014] Figure 1 The following are the steps performed by a task when accessing a kernel shared resource in a single-core system according to the prior art;

[0015] Figure 2 The present invention shows the steps performed by multiple tasks when accessing the core shared resources in a multi-core system according to the prior art;

[0016] Figure 3A It shows that according to the prior art, when a task wants to access kernel shared resources in a multi-core system, a single kernel lock is used for overall kernel protection;

[0017] Figure 3B It shows a specific lock for a specific core shared resource when a task wants to access a specific core shared resource in a multi-core system according to an embodiment disclosed in the present application;

[0018] Figure 4A is a block diagram of an apparatus for managing kernel services in a multi-core system according to an embodiment disclosed in the present application;

[0019] Figure 4B is a block diagram of a kernel resource engine of an apparatus for managing kernel services in a multi-core system according to an embodiment disclosed in the present application;

[0020] Figure 5 is a flowchart showing a method for managing kernel services in a multi-core system according to an embodiment disclosed in the present application;

[0021] Figure 6 is a flowchart showing a series of steps of an inter-process communication application program interface (IPC API) for object-specific locks of kernel-based shared resources according to an embodiment disclosed in the present application;

[0022] Figure 7 is an example showing a comparison between a conventional single kernel lock for accessing kernel shared resources and an object-specific lock for accessing kernel shared resources according to an embodiment disclosed in the present application;

[0023] Fig. 8A and Figure 8B is an example showing a comparison between interrupt locking of a conventional method and interrupt locking when an object-specific lock according to an embodiment disclosed in the present application is used to access kernel shared resources;

[0024] Fig. 9 is an example showing concurrent kernel service flows when object-specific locks are used to access a kernel's shared resources according to an embodiment of the present disclosure; and

[0025] Fig.10 FIG. 1 is an example showing how to execute tasks in parallel on two critical sections that are independent of each other using object-specific locks for accessing kernel shared resources according to an embodiment disclosed in the present application. DETAILED DESCRIPTION

[0026] Various embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. In the following description, only specific details such as detailed configuration and components are provided to help the overall understanding of these embodiments of the present disclosure. Thus, it is obvious to those skilled in the art that various changes and modifications may be made to the embodiments described in this application without departing from the scope and spirit of the present disclosure. In addition, for clarity and brevity, the description of known functions and structures is omitted.

[0027] Additionally, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments.

[0028] In this application, unless otherwise specified, the term "or" used in this application refers to non-exclusiveness. The examples used in this application are only intended to promote the understanding of the way in which the embodiments in this application can be practiced, and further enable those skilled in the art to practice the embodiments in this application. Therefore, the examples should not be interpreted as limiting the scope of the embodiments of this application.

[0029] As conventional in the art, embodiments can be described and illustrated according to the functional blocks described in the execution. In the present application, these blocks may refer to units, engines, managers, modules, etc., which are physically implemented by analog and / or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, storage circuits, passive electronic components, active electronic components, optical components, hard-wired circuits, etc., and may be optionally driven by firmware and / or software. The circuit may be implemented, for example, in one or more semiconductor chips or on substrate supports such as printed circuit boards. The circuits constituting the blocks may be implemented by dedicated hardware, or by a processor (e.g., one or more programmable microprocessors and associated circuits), or by a combination of dedicated hardware that performs certain functions of the module and a processor that performs other functions. Without departing from the scope of the present disclosure, each block of the embodiment may be physically divided into two or more interacting and discrete blocks. Similarly, without departing from the scope of the present disclosure, the blocks of the embodiment may be physically combined into more complex blocks.

[0030] Therefore, an embodiment of the present application provides a method for managing kernel services in a multi-core system. The method includes: configuring a common kernel lock for a kernel, configuring an object-specific lock for at least one shared resource of the kernel; and using the object-specific lock, processing IPC services for different shared resources on multiple cores of the multi-core system in parallel.

[0031] In one embodiment, parallel processing of IPC services for different shared resources on multiple cores of a multi-core system using object-specific locks includes: receiving a task request to obtain access to at least one object of kernel shared resources. The method also includes: acquiring an object-specific lock on the at least one object of kernel shared resources; and determining whether any scheduling operation needs to be performed by the kernel based on a given IPC operation on the kernel object. The task associated with the task request is suspended, preempted, or continued. A data structure of the shared resource is retrieved, and further based on the data structure, the task is suspended, preempted, or continued. If suspended, the object-specific lock is released and the scheduler is called to schedule an existing task in a ready state to a running state.

[0032] In one embodiment, to determine preemption, it is determined that the existing task is suspended, a task control block (TCB) of the existing task is retrieved from a shared resource, and is changed to a ready state. Further, it is determined that the retrieved TCB causes the task to be preempted. The object specific lock is then released, and a scheduler is called to perform a scheduling operation to put the existing task into a ready state to preempt the task associated with the task request.

[0033] In one embodiment, the execution of tasks is continued by determining that at least one task or no tasks are in a suspended state. Thus, if there are suspended tasks, the TCB of the task is retrieved and it is determined whether the TCB does not cause the task associated with the task request to be preempted. After releasing the object-specific lock, the scheduler is called to add the existing tasks to the ready queue. Alternatively, if no tasks are suspended, the object-specific lock is released and the method terminates.

[0034] In one embodiment, the shared resources include mutexes, semaphores, events, and message queues, wherein the object-specific locks include mutex-specific locks, semaphore-specific locks, event-specific locks, and message queue-specific locks.

[0035] In conventional multi-core systems supporting SMP, kernel services acquire common kernel locks to obtain exclusive access to kernel shared resources, which restricts the parallel execution of kernel object instances that are independent of each other when executed on different cores.

[0036] Unlike conventional multi-core systems, the proposed method allows kernel services to obtain exclusive access to kernel shared resources without using common kernel locks by providing kernel object instance specific locks. The use of kernel object instance specific locks provides significant advantages in handling kernel objects that are independent of each other on different cores.

[0037] Conventional multi-core systems use a common core lock to balance task scheduling of all cores on the multi-core system, which affects interrupt latency and thus real-time response.

[0038] In conventional multi-core systems, even if a task running on IPC does not require any kernel scheduling, the task will occupy a common kernel lock, which will increase the waiting time and keep other tasks waiting.

[0039] Conventional methods and systems do not classify IPCs with respect to IPC instances. As a result, all kernel services working on IPC objects treat IPCs as common kernel resources. For example, M1 and M2 are considered different IPC mutex objects, and then Mutex_Post() considers both M1 and M2 as a single critical resource that cannot be accessed simultaneously. Unlike conventional methods and systems, the proposed method considers both M1 and M2 as different resources because the proposed method relieves the interdependence of IPC objects and thus can be accessed simultaneously on different kernels.

[0040] In conventional multi-core systems, the kernel IPC API does not distinguish between IPC and kernel shared data; instead, both IPC and kernel shared data are treated as a single shared kernel resource protected by a common kernel lock. Unlike conventional methods and systems, the proposed method provides separate locks for IPC and kernel shared data.

[0041] Referring now to the drawings, and more particularly to Figures 1 to 10 , which shows a preferred embodiment, like reference numerals denote corresponding features throughout the drawings.

[0042] Figure 1 The figure shows the steps performed by a task when accessing a core shared resource in a single-core system according to the prior art.

[0043] Reference Figure 1 , consider Task A running on a single-core SMP system. At step 102, Task A needs to access the shared resources of the kernel. At step 104, the kernel scheduler disables interrupts (ISRs) to allow Task A to access the shared resources of the kernel.

[0044] At step 106, task A obtains access to the kernel's shared resources. In addition, task A processes and uses the kernel's shared resources. At step 108, when task A completes access to the kernel's shared resources, the kernel scheduler enables interrupts. In addition, at step 110, normal execution of task A continues. Access to kernel shared resources is obtained by tasks running only on a single core of an SMP system upon task request. However, in the case of a multi-core system, there are multiple cores, and at any given time instance, multiple tasks may be running on multiple cores.

[0045] Figure 2 The figure shows the steps that a plurality of tasks execute when accessing a multi-core system according to the prior art.

[0046] Reference Figure 2,Consider two cores in a multi-core system: core 0 and core 1, task A (at step 202) and task B (at step 212) are being executed simultaneously on the two cores. In addition, at steps 202 and 212, the kernel scheduler determines that both task A and task B need to access the critical portion of the corresponding core to obtain access to the shared resources of the kernel.

[0047] In a conventional multi-core system, when a task wants to obtain exclusive access to kernel shared resources, the task needs to acquire a common kernel lock. The common kernel lock restricts the parallel execution of kernel object instances associated with core kernel services (such as, for example, mutexes, semaphores, events, message queues, etc.) across multiple cores of the multi-core system, and these kernel object instances are independent of each other when executed on different cores.

[0048] Thus, in step 204, task A obtains the common kernel lock; thus, in step 206, task A accesses the shared resources of the kernel. However, in step 214, task B cannot obtain the common kernel lock that enables task B to access the shared resources of the kernel, and thus, in steps 216 to 218, task B waits to obtain access to the common kernel lock. The kernel object that task A is accessing and the kernel object that task B intends to access may be different. However, because the common kernel lock is used, task B is stopped from executing on kernel 1 until task A running on kernel 0 releases the common kernel lock.

[0049] At step 208, task A releases the common kernel lock, and the kernel scheduler sends an event to task B running on kernel 1, indicating that the common kernel lock can be acquired. Thus, at step 220, task B acquires the common kernel lock; and at step 222, task B accesses the shared resources of the kernel.

[0050] The common kernel lock used by the kernel is per-core and thus has no impact on a single-core system. However, in a multi-core system, when one core acquires the common kernel lock, execution on other cores stops, and the common kernel lock has a huge impact.

[0051] Figure 3A It shows overall kernel protection using a common kernel lock when a task wants to access kernel shared resources in a multi-core system according to the prior art.

[0052] In multi-core systems supporting SMP, kernel services acquire common kernel locks to gain exclusive access to kernel shared resources, which restricts parallel execution of independent kernel object instances when executing on different cores.

[0053] Reference Figure 3A, consider the circle, representing the common kernel lock for the kernel's shared resources (such as mutexes, semaphores, events, and message queues) and the kernel associated with core kernel services. Consider task A, running on core 0, which wants to access a semaphore associated with core kernel services. Thus, task A has acquired the common kernel lock and is using the semaphore. Consider task B, running on core 1, which wants to access a mutex associated with core kernel services. However, because the task has already acquired the common kernel lock, task B will not be able to access the mutex associated with core kernel services. Thus, even though the kernel object instance that task A is accessing is a semaphore rather than a mutex, task B cannot access the mutex until task A releases the common kernel lock.

[0054] Figure 3B FIG. 4 shows a specific lock for a specific core shared resource when a task wants to access a specific core shared resource in a multi-core system according to an embodiment disclosed in the present application. Figure 3B ,The proposed method solves the problem of ,exclusive object specific locks for the kernel’s shared resources. Figure 3A The limitations of the common kernel locks described above. Object-specific locks are represented by a circle around each of the kernel objects.

[0055] Reference Figure 3B , the proposed method provides object specific locks for each of the shared resources of the kernel. Consider that task A requests access to semaphore S1, task B requests access to semaphore S2, and task C requests mutex M1. The proposed method provides a specific lock for semaphore S1 (i.e., S1_lock), a specific lock for semaphore S2 (i.e., S2_lock), and a specific lock for mutex M1 (i.e., M1_lock). Therefore, since each of the shared resources of the kernel has a specific lock, tasks that have to access the shared resources of the kernel running on the same core or different cores will not be stalled.

[0056] Figure 4A It is a block diagram of an apparatus 400 for managing kernel services in a multi-core system according to an embodiment disclosed in the present application.

[0057] Consider an apparatus 400, including an operating system that supports SMP processing on a multi-core system. The operating system includes a kernel 420 that allows inter-task communication, signaling, and scheduling services. Based on scheduling schemes such as priority-based preemptive scheduling, time-slice-based scheduling logic, etc., the kernel 420 can schedule multiple tasks on multiple cores of the multi-core system (context switching of tasks). Tasks in the multi-core system transition between various states (such as ready state, suspended state, and running state). The kernel 420 includes a kernel resource engine 430. The apparatus 400 also includes a scheduler 440, a multi-core processor 460, and a memory 480.

[0058] In one embodiment, the apparatus 100 may be, for example, a mobile phone, a smart phone, a personal digital assistant (PDA), a tablet computer, a wearable device, an Internet of Things (IoT) device, or the like.

[0059] In one embodiment, kernel 420 is system software for managing device elements and software resources. The locking principle for RTOS described herein is also applicable to any system. Kernel resource engine 430 is configured to design locks for kernel 420. Kernel resource engine 430 is also configured to configure object specific locks for the shared resources of kernel. The shared resources of kernel include mutex, semaphore, event, message queue etc. Object specific locks include specific locks for the specific shared resources of kernel, i.e. mutex specific locks, semaphore specific locks, event specific locks and message queue specific locks. In addition, kernel resource engine 430 is also configured to use object specific locks to parallelly process IPC services for different shared resources on multiple cores of multi-core processor 460.

[0060] In one embodiment, the scheduler 440 is configured to schedule multiple tasks (context switching of tasks) based on a scheduling scheme such as, for example, priority-based preemptive scheduling, time-slice-based scheduling, etc. Since the tasks are scheduled by the scheduler 440, the tasks are switched between multiple states (such as ready, suspended, and running, etc.).

[0061] In one embodiment, the multi-core processor 460 is composed of multiple cores with interconnections between the cores. The multiple cores may be collectively referred to as cores, or generally referred to as cores. The multi-core processor 460 may be configured to read from and / or write to a memory 480. Such read and write operations may involve instructions and data associated with the operation of the multiple cores of the multi-core processor 460. In addition, each core within the multi-core processor 460 may be configured to access the memory 480 separately. Signaling between the multiple cores is achieved by generating a software-driven hardware interrupt to the multiple cores participating in the SMP.

[0062] In one embodiment, the memory 480 is configured to store instructions and data associated with the operation on the core of the multi-core processor 460. The memory 480 may include a non-volatile storage element. Examples of such non-volatile storage elements may include: a magnetic hard disk, an optical disk, a floppy disk, a flash memory, or an electrically programmable memory (EPROM) or an electrically erasable programmable (EEPROM) memory. In addition, in some examples, the memory 480 may be considered to be a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier or a propagated signal. However, the term "non-transitory" should not be interpreted as the memory 480 being non-removable. In some examples, the memory 480 is configured to store a larger amount of information than the memory. In some examples, a non-transitory storage medium may store data that may change over time (e.g., in a random access memory (RAM) or a cache).

[0063] although Figure 4A The hardware elements of the device 400 are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, the device 400 may include fewer or more elements. In addition, the labels or names of the elements are only for illustrative purposes and do not limit the scope of the present disclosure. One or more components can be combined together to perform the same or substantially similar functions of managing kernel services in a multi-core system.

[0064] Figure 4B It is a block diagram of a kernel resource engine 430 of an apparatus 400 for managing kernel services in a multi-core system according to an embodiment disclosed in the present application.

[0065] Reference Figure 4B The kernel resource engine 430 includes a shared resource manager 432 , an IPC service manager 434 , a task scheduler 436 and an IPC service monitor 438 .

[0066] In one embodiment, the shared resource manager 432 is configured to classify the kernel's shared resources, such as, for example, considering message queue (MQ) instances (eg, MQ1, MQ2, ..., MQn) of the kernel's shared resources as message queues (MQ).

[0067] In addition, shared resource manager 432 is configured to be designed for the lock of kernel and the object specific lock for each of kernel shared resources. In addition, shared resource manager 432 is also configured to be designed for the object specific lock of the specific shared resource of kernel. In addition, shared resource manager 432 is configured to associate the instance of shared resource with unique object specific lock, to access the separate shared resource exclusively in the cross multi-tasking environment executed on multi-core system. For example, consider that the shared resource of kernel is semaphore. Shared resource manager 432 is configured as a whole for semaphore semaphore specific lock, and also for each semaphore specific lock, such as semaphore S1 has object specific lock S1_lock, semaphore S2 has object specific lock S2_lock etc.

[0068] In addition, the shared resource manager 432 is configured to receive a request from at least one task to obtain access to at least one shared resource of the kernel, and determine at least one shared resource of the kernel that the at least one task needs to obtain access to. In addition, the shared resource manager 432 is further configured to acquire an object-specific lock on at least one shared resource of the kernel based on the request from at least one task. Thus, the object-specific lock allows multiple cores across a multi-core system to concurrently access the shared resources of the kernel without the task having to wait for a separate IPC object instance.

[0069] In one embodiment, the IPC service manager 434 is configured to retrieve an IPC data structure corresponding to an existing task that is accessing at least one shared resource of the kernel within an object-specific lock. IPC is a process provided by the OS that allows processes to manage shared data. IPC services can operate and modify the kernel's shared resources, such as message queues, events, semaphores, and mutexes, as well as maintain kernel data structures of the task control block (TCB), such as the task ready queue. IPC objects are interdependent and connected to kernel data structures running on the TCB.

[0070] In addition, the IPC service manager 434 is configured to retrieve the IPC data of the existing task from the structure and determine whether a scheduling operation needs to be performed on the task control block (TCB) based on the IPC data. The IPC service manager 434 includes an IPC service monitor integrated in the kernel IPC service implementation, and the IPC service monitor detects the need to call the task scheduler 436 in the current context of the IPC kernel service. When the task requesting access to the shared resource of the kernel 420 belongs to the same core as the running task, the task scheduler 436 is not called, and only the shared resource instance is processed by obtaining access to the object-specific lock.

[0071] In addition, the IPC service manager 434 is configured to: determine that an existing task on at least one shared resource of the kernel needs to be suspended in response to determining that a scheduling operation needs to be performed on the TCB; or, the IPC service manager 434 determines that it is not necessary to suspend the task on at least one shared resource of the kernel in response to determining that a scheduling operation does not need to be performed on the TCB. Thus, the IPC service manager 434 determines whether it is necessary to suspend the existing task accessing at least one shared resource of the kernel based on determining whether a scheduling operation needs to be performed on the TCB.

[0072] In one embodiment, the task scheduler 436 is configured to: execute the task with the highest priority on multiple cores of the multi-core system at any given point in time. Assign priorities to tasks and execute tasks in the ready state according to a preemptive scheduling scheme. The IPC service can change the state of tasks in the multi-core system and cause a transition from the running state to the suspended state, or from the running state to the suspended / ready state.

[0073] In addition, the task scheduler 436 is configured to: suspend an existing task accessing at least one shared resource of the kernel based on input from the IPC service manager 434; or the task scheduler 436 is configured to: allow an existing task accessing at least one shared resource of the kernel 420 to continue accessing the shared resources of the kernel 420 based on input from the IPC service manager 434. In addition, the task scheduler 436 is configured to determine whether it is necessary to suspend an existing task accessing at least one shared resource. The task scheduler 436 is configured to: in response to determining that it is not necessary to suspend an existing task on at least one shared resource, release an object-specific lock for at least one shared resource of the kernel 420, and schedule a task associated with the task request to access the at least one shared resource.

[0074] The task scheduler 436 is configured to: in response to determining that an existing task on at least one shared resource needs to be suspended, retrieve the existing task information from the message queue, and release the object-specific lock for at least one shared resource of the kernel. In addition, the task scheduler 436 is configured to block the task associated with the task request and acquire the lock for the kernel. In addition, the task scheduler 436 is configured to move the blocked task to a ready state for scheduling and release the lock for the kernel, and schedule the task associated with the task request to access the at least one shared resource.

[0075] In one embodiment, the IPC service monitor 438 is configured to determine the need for an invocation of the dispatcher 440 .

[0076] Figure 5 is a flowchart showing a method for managing kernel services in a multi-core system according to an embodiment disclosed in the present application.

[0077] Reference Figure 5 At step 502, the apparatus 400 configures a lock for the kernel 420 and an object-specific lock for a shared resource of the kernel 420. For example, Figure 4A In the illustrated apparatus 400 , the kernel resource engine 430 is configured to: configure locks for the kernel 420 , and configure object-specific locks for shared resources of the kernel 420 .

[0078] At step 504, the apparatus 400 receives a task request to obtain access to at least one shared resource of the kernel 420. For example, Figure 4A In the illustrated apparatus 400 , the kernel resource engine 430 is configured to receive a task request to obtain access to at least one shared resource of the kernel 420 .

[0079] At step 506, the apparatus 400 acquires an object-specific lock on at least one shared resource of the kernel 420. For example, Figure 4A In the illustrated apparatus 400, a kernel resource engine 430 is configured to acquire an object-specific lock on at least one shared resource of the kernel.

[0080] At step 508, the apparatus 400 retrieves an IPC data structure corresponding to an existing task on at least one shared resource of the kernel 420 within the object-specific lock. Figure 4A In the illustrated apparatus 400, the kernel resource engine 430 is configured to retrieve an IPC data structure corresponding to an existing task on at least one shared resource of the kernel within an object-specific lock.

[0081] In step 510, the apparatus 400 determines whether an IPC service specific operation is allowed on at least one shared resource. If the operation is not allowed, the request task is suspended and the task scheduler 436 is called on the operation to schedule the existing task to a running state.

[0082] In one embodiment, the apparatus 400 determines whether to perform a scheduling operation on a thread control block (TCB) based on the IPC data. Figure 4A In the illustrated apparatus 400 , the kernel resource engine 430 is configured to determine whether to perform a scheduling operation on a thread control block (TCB) based on IPC data.

[0083] In step 512, the apparatus 400 determines that the task on at least one shared resource of the kernel does not need to be in a suspended state in response to determining that the requested IPC service operation is allowed on at least one of the shared resource objects. Figure 4AIn the illustrated apparatus 400, the kernel resource engine 430 is configured to determine that a task on at least one shared resource of the kernel does not need to be in a suspended state. In addition, at step 512, TCB data is retrieved from a data structure of at least one shared resource object of the kernel.

[0084] In step 522, the apparatus 400 determines that a scheduling operation is to be performed and that the task associated with the task request needs to be suspended in response to determining that the requested IPC service operation is not allowed on at least one of the shared resource objects. Figure 4A In the illustrated apparatus 400, the kernel 420 is configured to determine that the task associated with the task request on at least one shared resource of the kernel needs to be suspended in response to determining that the requested IPC service operation is not allowed on at least one of the shared resource objects. If the IPC service specific operation is not allowed, the task associated with the task request is suspended, and the task scheduler 436 is called to schedule the ready existing task to the running state.

[0085] At step 514, the device 400 determines whether to not call the task scheduler 436 based on the retrieved TCB data. If the task scheduler 436 is not called, then at step 520, the device 400 releases the object-specific lock for at least one shared resource of the kernel and continues to execute the task associated with the task request. Figure 4A In the illustrated apparatus 400 , the kernel resource engine 430 is configured to release an object-specific lock of at least one shared resource of the kernel.

[0086] If the task scheduler 436 is called, then at steps 516 and 518, the object specific lock is released and the scheduler is called and the task associated with the task request is preempted based on the priority and core affinity of the TCB data retrieved from the data structure of at least one shared resource object of the kernel.

[0087] In one embodiment, the apparatus 400 schedules a task associated with a task request to access at least one shared resource. Figure 4A In the illustrated apparatus 400 , the kernel resource engine 430 is configured to schedule tasks associated with task requests to access at least one shared resource.

[0088] The various actions, actions, blocks, steps, etc. in the method can be performed in the order presented, in a different order, or simultaneously. In addition, in some embodiments, some actions, actions, blocks, steps, etc. can be omitted, added, modified, skipped, etc., without departing from the scope of the present disclosure.

[0089] Figure 6600 is a flowchart illustrating a series of steps for an inter-process communication application program interface (IPC API) for object-specific locks of kernel-based shared resources according to an embodiment of the present disclosure.

[0090] Reference Figure 6 , provides functionally independent processes that implement logical processing on one of the shared kernel resources.

[0091] At step 602, the IPC API begins execution within a single context of the IPC kernel service process.

[0092] At step 604, the IPC API acquires an object-specific lock associated with the IPC object for processing the IPC object. At step 606, since the IPC API has exclusive access to the IPC object, the IPC API modifies the IPC instance parameters associated with the IPC object based on demand.

[0093] At step 608, the IPC service monitor 438 determines whether the scheduler 440 needs to be called.

[0094] Upon determining that the scheduler 440 does not need to be called, at step 610 the IPC API releases the object specific lock associated with the IPC object and exits from the logical process on one of the shared kernel resources.

[0095] Upon determining that the scheduler 440 must be called, the IPC API releases the object-specific lock associated with the IPC object upon completion of processing of the IPC object instance, at step 612. Additionally, the IPC API secures a common kernel lock to access kernel data structures, at step 614. The IPC API performs scheduling operations such as task context processing, at step 616, and releases the common kernel lock after completing the scheduling operations, at step 618. Additionally, the IPC API exits from logical processing on one of the shared kernel resources.

[0096] Figure 7 is an example showing a comparison between a conventional single kernel lock for accessing kernel shared resources and an object-specific lock for accessing kernel shared resources according to an embodiment disclosed in the present application.

[0097] Consider using kernel object A (e.g., semaphore A) to limit the maximum usage of resource X to two. Consider using another kernel object B (e.g., semaphore B) to limit the maximum usage of resource Y to two. Task 1 executing on core 0 needs to acquire resource X twice, and task 2 executing on core 1 needs to acquire resource Y twice. Task 1, task 2, semaphore A, and semaphore B are all independent of each other.

[0098] In the conventional method, during time interval T1, task 1 has acquired the common kernel lock for accessing semaphore A, and task 2 needs to wait for task 1 to release the common kernel lock so that task 2 can acquire the common kernel lock to obtain semaphore B. During time interval T2, task 2 has acquired the common kernel lock for accessing semaphore B, and task 1 needs to wait for task 2 to release the common kernel lock so that task 1 can acquire the common kernel lock to obtain semaphore A. Similarly, during time intervals T3 and T4, task 2 and task 1 are waiting to acquire the common kernel lock to access semaphore B and semaphore A, which are independent of each other.

[0099] Unlike conventional methods, in the proposed method, at time interval T1, task 1 acquires the lock of semaphore A and task 2 acquires the lock of semaphore B. In addition, since there is no mutual dependency, task 1 and task 2 can be executed in parallel. Similarly, at time interval T2, task 1 acquires the lock of semaphore A and task 2 acquires the lock of semaphore B, and both are executed in parallel. Therefore, the proposed method provides 100% parallelization across multiple cores of a multi-core processing system.

[0100] The proposed approach provides disconnected IPC object instances and scheduler handling. Critical sections are separated using object-specific locks and common kernel locks, respectively, which provide integrity of kernel operations and highly parallel execution of independent IPC object instances.

[0101] Fig. 8A and Figure 8B FIG. 1 is an example showing a comparison between interrupt locking of a conventional method and interrupt locking when an object-specific lock according to an embodiment disclosed in the present application is used to access kernel shared resources.

[0102] In the conventional approach, when a task acquires a common kernel lock to access a critical section of code, the interrupts within the task are locked for a longer period of time until the task releases the common kernel lock, e.g. Fig. 8A shown.

[0103] Unlike conventional methods, the proposed method provides object-specific locks and specific locks for specific shared resources. Thus, kernel services are functionally divided, and object-specific locks reduce interrupt lock cycles without affecting the determinism of the device 400. Figure 8B ,The proposed method enables unlocking interrupts in more critical parts of the kernel without affecting determinism due to the size of the critical parts of the kernel being segmented.,Thus, the shorter the duration of the interrupt locking is, the better the time response is provided.

[0104] Additionally, segmenting critical parts of the kernel improves system behavior and allows the scheduler 440 to act on recent changes in the system. Thus, the proposed method also reduces redundancy in the system.

[0105] Fig. 9 is an example showing concurrent kernel service flows when object-specific locks are used to access shared resources of the kernel according to an embodiment disclosed in the present application.

[0106] Reference Fig. 9 , consider a multi-core processor with multiple cores (i.e., core 0, core 1, and core 2). Consider a first IPC kernel service executed on core 0 and a second IPC kernel service executed on core 1. The first IPC kernel service needs to access a first IPC object instance, i.e., a first event (Ev1); while the second IPC kernel service needs to access a second IPC object instance, i.e., a second event (Ev2). In the proposed approach, the inter-task communication kernel service operates and modifies IPC objects (e.g., message queues, events, semaphores, and mutexes), and maintains kernel data structures of the task control block (TCB) (e.g., task ready queue).

[0107] exist Fig. 9 , at time T1, the first IPC kernel service acquires the object-specific lock for EV1, i.e., acquires lock_Ev1. At time T2, the first IPC kernel service runs and modifies EV1. In addition, when it is determined that scheduling is not required, at time T3, the first IPC kernel service releases the object-specific lock for EV1. In addition, at time T4, the first IPC kernel service will continue to execute normally on core 0. Since Ev1 and Ev2 are independent of each other, when the first IPC kernel service is executed on core 0, the second IPC kernel service is simultaneously executed on core 1. Therefore, when processing independent IPC instances, the method allows the first IPC kernel service and the second IPC kernel service to be executed in parallel.

[0108] Additionally, during processing of the IPC specific data, the kernel specific data may also be simultaneously accessed by a third IPC kernel service (executing on core 2) by acquiring a common kernel lock.

[0109] Fig.10 The example of using an object-specific lock for accessing a shared resource of a kernel to execute tasks in parallel on two critical parts that are independent of each other according to an embodiment of the present application is shown.

[0110] When the IPC object instances being processed are different, parallelization can be achieved using the same IPC service running on multiple cores of a multi-core system. In conventional methods and systems, only one instance of an IPC service is accessed at any given time instance, and concurrent accesses enter a busy wait state.

[0111] Consider task A that is executing on core 0 and wants to acquire mutex M1 (step 1202a). Similarly, task B is executing on core 1 and wants to acquire mutex M2 (step 1202b). In the conventional method of using a common kernel lock, in the case where task A wants to access the shared resources of the kernel (such as mutex M1), then task A acquires the common kernel lock and enters the critical section of the code. When task A completes the execution of the critical section of the code, task A releases the common kernel lock. In addition, task B can access the shared resources of the kernel only after task A releases the common kernel lock after completing the execution of the critical section of the code.

[0112] Reference Fig.10 ,Different from the conventional methods, the proposed method provides object ,specific locks to the kernel’s shared resources and also provides a specific lock ,for each of the specific shared resources.

[0113] At step 1204a, task A acquires an object specific lock for a specific mutex M1, ie, IPC_LOCK(m1_spin_object).

[0114] At step 1206a, task A determines whether mutex M1 is available. In addition, when it is determined that mutex M1 is available, task A acquires mutex M1 (step 1208a) and enters the critical section of the code and executes (step 1210a). In addition, when execution in the critical section of the code is completed, task A releases the object-specific lock for the specific mutex M1 (step 1212a). At step 1206a, if task A determines that mutex M1 is not available, task A releases the object-specific lock for the specific mutex M1 (step 1214a), and suspends task A (step 1216a) until task A acquires mutex M1.

[0115] In parallel, at step 1204b, task B executed on core 1 acquires an object-specific lock, i.e., IPC_LOCK(m2_spin_object), for a specific mutex M2, and performs steps 1106b to 1116b similar to task A, because kernel resources are segmented and kernel object-specific, i.e., mutex_1 and mutex_2 can both be acquired simultaneously without waiting for each other, thus, the proposed method of utilizing multiple kernel object-specific locks allows two critical sections that are independent of each other to be executed in parallel.

[0116] The above description of specific embodiments will fully reveal the general characteristics of the embodiments in the present application, so that others can easily modify and / or adapt to the various applications of these specific embodiments by applying current knowledge without departing from the common concept. Therefore, such adaptations and modifications should and are intended to be understood as being within the meaning and scope of the equivalent forms of the disclosed embodiments. It should be understood that the wording or terminology used in this application is for descriptive purposes rather than limiting. Therefore, although the embodiments of the present application have been described according to preferred embodiments, those skilled in the art will recognize that the embodiments of the present application can be implemented by modifications within the spirit and scope of the embodiments as described herein.

Claims

1. A method for managing kernel services in a multi-core system, comprising: configuring a common kernel lock for a kernel and configuring an object specific lock for at least one shared resource of the kernel; In the process of processing kernel data of an inter-process communication (IPC) service of at least one core among the multiple cores of the multi-core system based on the common kernel lock: receiving a task request to obtain access to at least one shared resource object of the kernel, wherein the task request is one of an IPC service for different shared resources on the plurality of cores based on the object specific lock; acquiring an object specific lock of the object specific locks associated with the task request on the at least one shared resource object of the kernel; determining a task associated with the task request on the at least one shared resource object of the kernel, and Based on the object specific lock and the determined task, IPC data of the IPC service is processed.

2. The method according to claim 1, wherein: The at least one shared resource includes a mutex, a semaphore, an event, and a message queue. The object-specific locks include mutex-specific locks, semaphore-specific locks, event-specific locks and message queue-specific locks.

3. The method according to claim 1, wherein: In the event that the task associated with the task request on the at least one shared resource object of the kernel is suspended, the method further comprises: retrieving an IPC data structure of the at least one shared resource object within the object-specific lock; determining that the requested IPC service specific operation is not allowed on the at least one shared resource object of the kernel; suspending the task associated with the task request to be suspended on the at least one shared resource object of the kernel; releasing the object specific lock; and Calls the scheduler to schedule an existing task in the Ready state to the Running state.

4. The method according to claim 1, wherein: In the event that the task associated with the task request on the at least one shared resource object of the kernel is preempted, the method further comprises: retrieving an IPC data structure of the at least one shared resource object within the object-specific lock; determining whether the requested IPC service specific operation is allowed on the at least one shared resource object of the kernel; determining that at least one existing task is in a suspended state on the at least one shared resource object of the kernel; Retrieving a task control block TCB of at least one existing suspended task from the at least one shared resource object of the kernel and changing it to a ready state; determining whether the retrieved TCB causes the task associated with the task request to be preempted; releasing the object specific lock; and A scheduler is called to perform a scheduling operation, and the existing task is placed in a ready state to preempt the task associated with the task request.

5. The method according to claim 1, wherein: In case the task associated with the task request on the at least one shared resource object of the kernel continues to execute, the method further comprises: retrieving an IPC data structure of the at least one shared resource object within the object-specific lock; determining that the requested IPC service specific operation is allowed on the at least one shared resource object of the kernel; determining that at least one existing task is in a suspended state on the at least one shared resource object of the kernel; Retrieving a task control block TCB of at least one existing suspended task from the at least one shared resource object of the kernel, and changing its state to a ready state; determining that the retrieved TCB will not result in preemption of the task associated with the task request; releasing the object specific lock; and Calls the scheduler to add an existing task to the ready queue.

6. The method according to claim 1, wherein: In case the task associated with the task request on the at least one shared resource object of the kernel continues to execute, the method further comprises: retrieving an IPC data structure of the at least one shared resource object within the object-specific lock; determining that the requested IPC service specific operation is allowed on the at least one shared resource object of the kernel; Determining that no tasks are pending on the retrieved data structure; and Releases the object specific lock.

7. The method according to claim 1, further comprising: Detect scheduler call events; Unblocking access to a data structure handled by a specific kernel service application program interface API and blocking access to a second specific kernel service application program interface for scheduling; as well as After the scheduling is completed, the access block to the second specific kernel service application program interface is released.

8. An apparatus for managing kernel services in a multi-core system, comprising: Memory; Multi-core processors including multiple cores; as well as a kernel executing on the multi-core processor, The kernel includes a kernel resource engine and a kernel scheduler. Wherein, the kernel resource engine is connected to the multi-core processor and the memory, and the kernel resource engine is configured as follows: configuring a common kernel lock for the kernel and configuring an object specific lock for at least one shared resource of the kernel; In the process of processing kernel data of an inter-process communication (IPC) service of at least one core among the multiple cores of the multi-core system based on the common kernel lock: receiving a task request to obtain access to at least one shared resource object of the kernel, wherein the task request is one of an IPC service for different shared resources on the plurality of cores based on the object specific lock; acquiring an object specific lock of the object specific locks associated with the task request on the at least one shared resource object of the kernel; determining a task associated with the task request on the at least one shared resource object of the kernel, and Based on the object specific lock and the determined task, IPC data of the IPC service is processed.

9. The device according to claim 8, wherein: In the case that the task associated with the task request on at least one shared resource object of the kernel needs to be suspended, the kernel resource engine is further configured to: retrieving an IPC data structure of at least one shared resource object within the object-specific lock; determining whether a requested IPC service specific operation is not allowed on at least one shared resource object of the kernel; suspending the task associated with the task request to be suspended on at least one shared resource object of the kernel; releasing the object specific lock; as well as Calls the scheduler to schedule an existing task in the Ready state to the Running state.

10. The device according to claim 8, wherein: In the event that the task associated with the task request on the at least one shared resource object of the kernel needs to be preempted, the kernel resource engine is further configured to: retrieving an IPC data structure of at least one shared resource object within the object-specific lock; determining that a requested IPC service specific operation is allowed on the at least one shared resource object of the kernel; determining that at least one existing task is in a suspended state on the at least one shared resource object of the kernel; Retrieving a task control block TCB of at least one existing suspended task from the at least one shared resource object of the kernel and changing it to a ready state; determining that the retrieved TCB causes the task associated with the task request to be preempted; releasing the object specific lock; as well as The scheduler is called to perform a scheduling operation to put an existing task into a ready state to preempt the task associated with the task request.

11. The device according to claim 8, wherein: In the case where the task associated with the task request on the at least one shared resource object of the kernel needs to continue execution, the kernel resource engine is further configured to: retrieving an IPC data structure of at least one shared resource object within the object-specific lock; determining that a requested IPC service specific operation is allowed on the at least one shared resource object of the kernel; determining that at least one existing task is in a suspended state on the at least one shared resource object of the kernel; Retrieving a task control block TCB of at least one existing suspended task from the at least one shared resource object of the kernel, and changing its state to a ready state; determining that the retrieved TCB will not result in preemption of the task associated with the task request; releasing the object specific lock; Calls the scheduler to add an existing task to the ready queue.

12. The device according to claim 8, wherein: In the case where the task associated with the task request on the at least one shared resource object of the kernel needs to continue execution, the kernel resource engine is further configured to: retrieving an IPC data structure of the at least one shared resource object within the object-specific lock; determining that a requested IPC service specific operation is allowed on the at least one shared resource object of the kernel; Determining that no task is in a suspended state on the shared resource object of the kernel; as well as Releases the object specific lock.

Images