# US 2019/0317827 A1 · Method and apparatus for managing kernel services in multi-core system > Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt - Number: US 2019/0317827 A1 - Document ID: US20190317827A1 - Status: Published application - Kind: A1 - Application number: 16/386,969 - Filed: 2019-04-17 - Published: 2019-10-17 - Earliest claimed: 2018-04-17 - Assignees: Samsung Electronics Co., Ltd. - Applicants: Samsung Electronics Co., Ltd. - Inventors: Anup Manohar KAVERI; Vinayak HANAGANDI; Nischal JAIN; Rohit Kumar SARAF; Shwetang SINGH; Samarth VARSHNEY; Srinivasa Rao KOLA; Younjo OH - Web page: https://patentgrep.com/patent/US20190317827A1 ## CPC - G06F 9/5077: {Logical partitioning of resources; Management or configuration of virtualized resources (specific details on emulation or internal functioning of virtual machines G06F9/455)} - G06F 9/526: {Mutual exclusion algorithms} - G06F 9/3885: {using a plurality of independent parallel functional units} - G06F 9/4881: {Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues} - G06F 21/6281: {at program execution time, where the protection is within the operating system} - G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N) ## Abstract The present disclosure provides method and apparatus for managing kernel services in multi-core system. Embodiments herein provide a method for managing kernel services in a multi-core system. The method includes configuring a lock for a kernel and object-specific locks for shared resources of the kernel and parallel processing IPC services for different shared resources on a plurality of cores of the multi-core system using the object-specific locks. ## Claims ### Claim 1 A method for managing kernel services in a multi-core system, comprising: configuring a common kernel lock for a kernel and object-specific locks for at least one shared resource of the kernel; and processing at least one inter process communications (IPC) services for different shared resources on at least one core of a plurality of cores of the multi-core system using the object-specific locks. ### Claim 2 (depends on 1) The method of claim 1, wherein the at least one shared resource includes a mutex, a semaphore, an event, a message queue, and wherein the object-specific locks includes a mutex-specific lock, a semaphore-specific lock, an event-specific lock, and a message queue-specific lock. ### Claim 3 (depends on 1) The method of claim 1, wherein processing the at least one IPC services includes at least one of parallel processing and non-parallel processing. ### Claim 4 (depends on 3) The method of claim 3, wherein the parallel processing comprises: receiving a task request to get access to at least one shared resource object of the kernel; acquiring an object-specific lock, by the task, on the at least one shared resource object of the kernel; and determining whether the task associated with the task request on the at least one shared resource object of the kernel is at least one of suspended, preempted and continued. ### Claim 5 (depends on 4) The method of claim 4, wherein determining whether the task associated with the task request on the at least one shared resource object of the kernel is suspended comprises: retrieving the at least one shared resource object's data structure inside the object specific lock; determining that a 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 invoking a scheduler to schedule an existing task in a ready state to a running state. ### Claim 6 (depends on 4) The method of claim 4, wherein determining whether the task associated with the task request on the at least one shared resource object of the kernel is preempted comprises: retrieving the at least one shared resource object's data structure inside the object-specific lock; determining whether a requested IPC service specific operation is allowed on the at least one shared resource object of the kernel; determining at least one existing task is in suspended state on the at least one shared resource object of the kernel; retrieving a task control block (TCB) of the at least one existing suspending 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 preemption of the task associated with the task request; releasing the object specific lock; and invoking the scheduler to take scheduling action and place the existing task in a ready state to preempt the task associated with the task request. ### Claim 7 (depends on 4) The method of claim 4, wherein determining whether the task associated with the task request on the at least one shared resource object of the kernel is continued comprises: retrieving the at least one shared resource object's data structure inside the object specific lock; determining the requested IPC service specific operation is allowed on the at least one shared resource object of the kernel; determining at least one existing task is in suspended state on the at least one shared resource object of the kernel; retrieving a task control block (TCB) of the at least one existing suspending task from the at least one shared resource object of the kernel and changing its state to a ready state; determining the retrieved TCB does not cause the preemption of the task associated with the task request; releasing the object specific lock; and invoking the scheduler to add an existing task to a ready queue. ### Claim 8 (depends on 4) The method of claim 4, wherein determining whether the task associated with a task request on the at least one shared resource object of the kernel continues its execution comprises: retrieving the at least one shared resource object's data structure inside the object specific lock; determining a requested IPC service specific operation is allowed on the at least one shared resource object of kernel; determining no task is in suspended state on the retrieved data structure; and releasing the object specific lock. ### Claim 9 (depends on 1) The method of claim 1, further comprises: detecting a scheduler invocation event; unblocking access to the data structure worked upon by a specific kernel service application programming interface (API) and blocking access to a second specific kernel service API for scheduling; and unblocking access to the second specific kernel service API after the scheduling is completed. ### Claim 10 An apparatus for managing kernel services in a multi-core system, comprising: a memory; a multi-core processor comprising a plurality of cores; and a kernel to execute on the multi-core processor, wherein the kernel comprises a kernel resource engine and a kernel scheduler, wherein the kernel resource engine, coupled to the multi-core processor and the memory, configured to: configuring a common kernel lock for the kernel and object-specific locks for at least one shared resource of the kernel; and processing at least one inter process communications (IPC) services for the at least one shared resource on at least one core of a plurality of cores of the multi-core system using the object-specific locks. ### Claim 11 (depends on 10) The apparatus of claim 10, wherein the shared resources includes a mutex, a semaphore, an event, a message queue, and wherein the object-specific locks includes a mutex-specific lock, a semaphore-specific lock, an event-specific lock, and a message queue-specific lock. ### Claim 12 (depends on 10) The apparatus of claim 10, wherein processing the at least one IPC services includes at least one of parallel processing and non-parallel processing. ### Claim 13 (depends on 12) The apparatus of claim 12, wherein the parallel processing comprises: receiving a task request to obtain access to at least one shared resource object of the kernel; acquiring an object-specific lock on the at least one shared resource object of the kernel; determining whether a task associated with a task request on the at least one shared resource object of the kernel needs to be suspended; determining whether the task associated with the task request on the at least one shared resource object of the kernel needs to be preempted; and determining whether the task associated with the task request on the at least one shared resource object of the kernel needs to continue its execution. ### Claim 14 (depends on 10) The apparatus of claim 10, wherein determining whether the task associated with task request on at least one shared resource object of the kernel needs to be suspended comprises: retrieving at least one shared resource object's data structure inside 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; and invoking a scheduler to schedule an existing task in ready state to running state. ### Claim 15 (depends on 10) The apparatus of claim 10, wherein determining whether the task associated with the task request on the at least one shared resource object of the kernel needs to be preempted comprises: retrieving at least one shared resource object's data structure inside the object specific lock; determining a requested IPC service specific operation is allowed on the at least one shared resource object of the kernel; determining at least one existing task is in suspended state on the at least one shared resource object of the kernel; retrieving a TCB of the at least one existing suspending task from the at least one shared resource object of the kernel and changing it to ready state; determining the retrieved TCB causes the preemption of the task associated with the task request; releasing the object specific lock; and invoking a scheduler to take scheduling action and make an existing task in a ready state to preempt the task associated with the task request. ### Claim 16 (depends on 10) The apparatus of claim 10, wherein determining whether the task associated with the task request on the at least one shared resource object of the kernel needs to continue its execution comprises: retrieving at least one shared resource object's data structure inside the object specific lock; determining a requested IPC service specific operation is allowed on the at least one shared resource object of the kernel; determining the at least one existing task is in suspended state on the at least one shared resource object of the kernel; retrieving a TCB of the at least one existing suspending 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 does not cause the preemption of the task associated with the task request; releasing the object specific lock; invoking a scheduler to add an existing task to a ready queue. ### Claim 17 (depends on 10) The apparatus of claim 10, wherein determining whether the task associated with the task request on the at least one shared resource object of the kernel needs to continue its execution comprises: retrieving at least one shared resource object's data structure inside the object specific lock; determining a requested IPC service specific operation is allowed on the at least one shared resource object of the kernel; determining no task is in suspended state on the retrieved shared resource object of the kernel; and releasing the object specific lock. ### Claim 18 A method for providing low latency kernel services in a multi-core operating system, the method comprising; receiving, by a kernel, a system call for a specific kernel service application programming interface (API) from a first task being executed on at least one core wherein the system call refers to at least one data structure; determining availability of the specific kernel service API for the at least one data structure on receiving the system call; blocking, by the kernel, a core from accessing the at least one data structure worked upon by the specific kernel service API and initiating operation on the specific kernel service API; and unblocking the at least one data structure on completion of the operation on the specific kernel service API.