A microkernel optimization method for an Internet of Things operating system

Abstract

The present invention relates to the technical field of operating systems, and discloses a microkernel optimization method for an Internet of Things operating system. A plurality of Internet of Things devices and server devices are provided in the Internet of Things, and the Internet of Things operating system is applied to each of the Internet of Things devices and the server devices; the microkernel optimization method includes a system interface merging method, a thread ready queue delay update process, a specified thread call process, a thread lock release process, a capability word delegation process, and a capability word delegation revocation process. The technical solution of the present invention has the beneficial effect of providing a microkernel optimization method for an Internet of Things operating system, which can realize functions such as thread management, address space management, inter-thread communication, interrupt processing, etc., while taking into account all underlying functions and flexible microkernel architecture design, and avoiding circular dependencies between different modules.

Description

Technical Field

[0001] The invention relates to the technical field of operating systems and discloses a microkernel optimization method for an Internet of Things operating system. Background Art

[0002] The microkernels of existing IoT operating systems are already modularized, and well-defined interfaces are used between modules. The source code has been divided into subsystems, modules, and submodules. Different subsystems are almost completely independent parts of the microkernel, such as libraries for simple memory management, simplified C libraries, or the main kernel image itself. Each subsystem consists of one or more modules that encapsulate logical units. For example, the thread module contains the data structures and methods required to handle UHomeOS threads. The interfaces of these modules are well defined, hiding the implementation details. Similarly, modules can aggregate one or more submodules, which are used to further subdivide the modules into smaller logical blocks.

[0003] Traditional kernel synchronization mechanisms, such as semaphores and optional lock mechanisms, have problems such as thread deadlock and priority inversion, which are particularly serious for the real-time characteristics of consumer and industrial IoT systems with time constraints, because these kernel lock synchronization mechanisms will cause threads to compete for critical areas in multi-processors, causing a significant decline in system performance and real-time performance. Factors affecting service response time include interrupt delay, interrupt processing delay, scheduler delay, task scheduling delay, delays in various synchronization, mutual exclusion and communication measures between threads, and unpredictable delays caused by priority inversion. Summary of the invention

[0004] In view of the above problems existing in the prior art, a microkernel optimization method of an Internet of Things operating system is now provided. A plurality of Internet of Things devices and server devices are arranged in the Internet of Things, and the Internet of Things operating system is applied to each of the Internet of Things devices and the server devices;

[0005] The microkernel optimization method includes a system interface merging method, specifically including:

[0006] In the Internet of Things operating system, the first system interface responsible for sending information and the second system interface responsible for receiving information are associated with the same thread, so that during a communication between the Internet of Things device and the server device, the Internet of Things operating system at each end only executes two system calls.

[0007] Preferably, a delayed update process of a thread ready queue is also included, specifically including:

[0008] Step A1, the system scheduler of the IoT operating system traverses the system and obtains all threads that are currently ready;

[0009] Step A2, the system scheduler adds all other ready threads except the currently executing threads to the thread ready queue;

[0010] Step A3: When the system scheduler traverses the thread ready queue next time, the unready thread is deleted from the thread ready queue.

[0011] Preferably, the process of specifying thread calling is also included, which specifically includes:

[0012] After the task of sending data using a first type of thread is completed, the system scheduler of the Internet of Things operating system directly designates the next thread to be scheduled as a second type of thread, which corresponds to the first type of thread and is used to perform the task of receiving data.

[0013] Preferably, a thread lock release process is also included, which specifically includes:

[0014] Step B1, during the operation of a first thread having a thread lock, the IoT operating system receives a thread lock acquisition request of a second thread;

[0015] Step B2, the IoT operating system determines whether the second thread meets a preset thread lock preemption standard:

[0016] When the second thread meets the thread lock preemption standard, the IoT operating system transfers the thread lock from the first thread to the second thread, and then returns to step B1;

[0017] When the second thread does not meet the thread lock preemption standard, the IoT operating system moves the second thread to the top of a helper thread stack and keeps the second thread always in a ready state;

[0018] Step B3, the Internet of Things operating system transfers the thread resources of the thread at the top of the helping thread stack to the running first thread, until the first thread is executed and releases the thread lock, and then transfers the thread lock to the thread at the top of the helping thread stack.

[0019] Preferably, in step B2, the preset thread lock preemption standard is: the priority of the second thread is greater than or equal to the priority of the first thread.

[0020] Preferably, in step B3, the thread resources include the scheduling context, time slice and priority of the thread.

[0021] Preferably, a capability word list including capability words for indicating different permissions is pre-set in the IoT operating system, and the IoT operating system pre-assigns different capability words in the capability word list to different threads, and the capability words are respectively stored in a storage space;

[0022] An object address space is set in the memory space of the IoT operating system, and a plurality of indirect pointing objects are set in the object address space, each of the indirect pointing objects points to a different capability word;

[0023] The microkernel optimization method further includes a capability delegation process, which specifically includes:

[0024] The indirect pointing object is set to point to one of the capability words, and the indirect pointing object is assigned to one of the threads, thereby delegating the pointed capability word to the thread.

[0025] Preferably, the method further includes a process of revoking the authorization of the capability word, which specifically includes:

[0026] The indirect pointing object assigned to the thread is set to point to a null object, thereby revoking the capability word delegated to the thread.

[0027] The beneficial effect of the technical solution of the present invention is that it provides a microkernel optimization method for an Internet of Things operating system, which can realize functions such as thread management, address space management, inter-thread communication, interrupt processing, etc., while taking into account all underlying functions and flexible microkernel architecture design to avoid circular dependencies between different modules. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The embodiments of the present invention will be described more fully with reference to the attached drawings, which are provided for illustration and description only and are not intended to limit the scope of the present invention.

[0029] Figure 1 It is a schematic diagram of the structure of microkernel communication in the prior art;

[0030] Figure 2 A schematic diagram of a flow chart of a delayed update process in a preferred embodiment of the present invention;

[0031] Figure 3 The figure is a flow chart of the thread lock release process in a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0032] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0033] It should be noted that, unless there is any conflict, the embodiments and features in the embodiments of the present invention.

[0034] In the prior art, microkernel IPC (Inter Process Communication) can be implemented as follows: Figure 1 As shown, it includes a network subsystem 01, a driver service 02, a microkernel 03 and hardware 04. When the network subsystem 01 and the driver service 02 perform IPC communication, the kernel is trapped and exited 4 times and context switches are performed 2 times, while the kernel only needs to call kernel functions. It can be seen that inter-process communication affects the efficiency of the microkernel IPC performance.

[0035] In addition, inter-process communication (IPC) is usually divided into two modes: synchronous and asynchronous. Synchronous IPC means that the sender blocks and waits for the receiver to receive information. Generally, the information sent is not buffered, and the sender directly transmits the information to the receiver. Asynchronous IPC means that the sender does not have to wait for the receiver to receive the information, and the sender continues to execute. Generally, there is a send buffer. If the receiver arrives, the buffer information is transmitted to the receiver. The advantages of synchronous IPC are simple, fast, efficient, and less susceptible to denial attacks.

[0036] The present invention provides a microkernel optimization method for an Internet of Things operating system. A plurality of Internet of Things devices and server devices are arranged in the Internet of Things, and the Internet of Things operating system is applied to each of the Internet of Things devices and the server devices.

[0037] The microkernel optimization method includes a system interface merging method, specifically including:

[0038] In the IoT operating system, the first system interface responsible for sending information and the second system interface responsible for receiving information are associated with the same thread, so that during a communication between the IoT device and the server device, the IoT operating system at each end only executes two system calls.

[0039] Specifically, the present invention adopts a multi-server system architecture design model, that is, a synchronous client / server system model, which can call the first system interface call and the second system interface serve. Through the first system interface call and the second system interface serve, the sent message and the received message are bound to the same thread object. The client's first system interface call performs the sending and receiving operations, and the server system calls the second system interface serve to perform the reply and acceptance operations. In the IPC implementation mechanism, it not only supports independent sending and receiving operation processing, but also realizes the reply and acceptance merge processing operations. It can be seen that the merging method provided by the present invention can reduce the number of IPC system calls, that is, each RPC only uses 2 system calls instead of 4 system calls each, thereby solving the problem that the IPC call process in the prior art is very time-consuming.

[0040] In a preferred embodiment of the present invention, a delayed update process of a thread ready queue is also included, such as Figure 2 As shown, specifically including:

[0041] Step A1, the system scheduler of the IoT operating system traverses the system and obtains all threads that are currently ready;

[0042] Step A2: the system scheduler adds all ready threads except the currently executing threads to the thread ready queue;

[0043] Step A3: When the system scheduler traverses the thread ready queue next time, the unready thread is deleted from the thread ready queue.

[0044] Specifically, in the client / server model, the client calls the first system interface call to send a request to the server, then blocks and waits for a reply. The server usually calls the second system interface serve to block until a request comes in, then processes the request, sends a reply and blocks again. For the ready queue of the scheduler, the ready thread must be queued in the ready queue so that the consistency of the ready queue can be maintained. Then the client / server model needs to update the ready queue multiple times. The existing technologies that usually implement this operation include: (1) After the client sends a request, the client enters a blocked state and waits, is no longer ready, and must be dequeued from the ready queue; (2) After the server receives the request, the server enters the ready stage and must enter the ready queue; (3) After the server sends a reply, the server blocks again and must be dequeued from the ready queue; (4) After the client receives the reply, the client will be ready again and must enter the ready queue.

[0045] However, the above technologies will lead to frequent operation of the ready queue, which will lead to a serious degradation of the IPC performance of the microkernel. The present invention, in the UHomeOS microkernel, controls all ready threads except the currently executing thread to be placed in the ready queue through the delayed update process of the thread ready queue. The non-ready thread will not be deleted from the ready queue when blocked, but will be deleted from the ready queue the next time the scheduler traverses the ready queue, which can reduce the operation process of the ready queue and improve the IPC performance.

[0046] In a preferred embodiment of the present invention, a process of specifying thread calling is also included, which specifically includes:

[0047] After the task of sending data using a first-class thread is completed, the system scheduler of the IoT operating system directly designates the next thread to be scheduled as a second-class thread, which corresponds to the first-class thread and is used to perform the task of receiving data.

[0048] Specifically, in the client / server model, in the first case of IPC communication, when both parties are ready, unlike the prior art, the control calls the system scheduler to select the next scheduling thread, but directly switches the control scheduler to the context of the communication partner, in order to speed up the execution speed of the communication partner and donate the current remaining time slice to it, so as to complete its acceptance task as soon as possible. The specific implementation process may include the process of specifying thread calls, that is, the thread sending data can directly specify the next scheduled thread as the receiving thread after sending the data. At this time, the thread receiving the data can be directly scheduled to receive the data. By directly switching threads here and performing targeted scheduling switching of threads, the waiting time of both communication parties can be significantly improved, and the IPC performance of the communication partner can be improved.

[0049] In a preferred embodiment of the present invention, a thread lock release process is also included, such as Figure 3 As shown, specifically including:

[0050] Step B1, during the operation of a first thread having a thread lock, the IoT operating system receives a thread lock acquisition request from a second thread;

[0051] Step B2: The IoT operating system determines whether the second thread meets a preset thread lock preemption standard:

[0052] When the second thread meets the thread lock preemption standard, the IoT operating system transfers the thread lock from the first thread to the second thread, and then returns to step B1;

[0053] When the second thread does not meet the thread lock preemption standard, the IoT operating system moves the second thread to the top of a helper thread stack and keeps the second thread always in a ready state;

[0054] Step B3, the IoT operating system transfers the thread resources of the thread at the top of the helping thread stack to the running first thread, until the first thread is executed and releases the thread lock, and then transfers the thread lock to the thread at the top of the helping thread stack.

[0055] In a preferred implementation manner of the present invention, in step B2, the preset thread lock preemption standard is: the priority of the second thread is greater than or equal to the priority of the first thread.

[0056] In a preferred implementation manner of the present invention, in step B3, the thread resources include the scheduling context, time slice and priority of the thread.

[0057] Specifically, the present invention can realize a wait-free lock when applied to the release process described above. The wait-free lock is a non-blocking synchronization mechanism. If a thread detects a conflict before accessing the critical section, it does not block and wait for the thread operation in the critical section to complete, but continues to run to help the thread in the critical section to complete the operation, and then performs the critical section operation, ensuring that all threads can complete the critical section operation in a limited time, and also significantly improves the real-time performance of the system. However, due to the high complexity of the wait-free lock algorithm, few operating systems currently implement this synchronization mechanism lock. In the present invention, combined with the characteristics of the UHomeOS thread scheduling mechanism, through steps B1 to B3, thread resources are transferred by time slice donation, priority inheritance, etc., which can greatly simplify the implementation process of the wait-free lock and realize a wait-free lock mechanism without priority inversion problems.

[0058] In a specific embodiment, if the second thread A wants to acquire the lock currently held by the first thread B, and the first thread B is ready to run, the priority of the second thread A must be equal to or greater than the priority of the first thread B, otherwise it will not be able to preempt the first thread B to run. The second thread A cannot acquire the lock immediately, so it is placed at the top of the helper thread stack of the lock and helps the first thread B release the lock. This is done by donating the second thread A and its scheduling context as well as time and priority to the first thread B. The threads in the helper thread stack remain in a ready state and continue to be donated to the lock owner, the first thread B, each time the scheduler reactivates the second thread A, until the first thread B releases the lock and passes its lock to the second thread A at the top of the helper thread stack.

[0059] As can be seen from the above, not only can the wait-free lock mechanism be implemented, but also, in the actual operation process, the critical section synchronization performance overhead is reduced, and the real-time problem of the synchronization lock of the Internet of Things system is better solved.

[0060] In a preferred embodiment of the present invention, a capability word list including capability words for indicating different permissions is pre-set in the IoT operating system, and the IoT operating system pre-assigns different capability words in the capability word list to different threads, and the capability words are respectively stored in a storage space;

[0061] An object address space is set in the memory space of the IoT operating system, and a plurality of indirect pointing objects are set in the object address space, each of the indirect pointing objects points to a different capability word;

[0062] The microkernel optimization method also includes a capability delegation process, which specifically includes:

[0063] The indirect pointing object is set to point to a capability word, and the indirect pointing object is assigned to a thread, thereby delegating the pointed capability word to the thread.

[0064] In a preferred embodiment of the present invention, a process of revoking the authorization of a capability word is also included, which specifically includes:

[0065] Set the indirect pointer object assigned to the thread to point to a null object, thereby revoking the capability word delegated to the thread.

[0066] Specifically, a capability word is a token, ticket or key that grants the owner access to an entity or object in a computer system, usually including an identifier and access rights. The former is a name, such as thread, task, thread, etc., and the latter is permissions such as read, write, execute, access, etc. The capability word represents the operation permission on the identifier object. Capability word delegation is the subject delegating its capability words to other subjects, and revocation is the subject revoking the capability words it delegated to other subjects.

[0067] With respect to the delegation process, the present invention grants the capability word delegation operation to the client and the server by presetting the capability word. The client can use the initial capability word to communicate with the server, and the server queries the capability word in its object address space, thereby ensuring secure and reliable communication.

[0068] With regard to the revocation process, it is usually very difficult to revoke the permission of a capability word in the prior art. However, in the object address space, the present invention only needs to set an indirect object to execute an empty object by indirectly pointing to the object instead of storing the object itself, which effectively solves the problem of capability word invalidation.

[0069] As can be seen from the above, the technical solution applied to the present invention, from the perspective of security, the initial capability word, that is, the access rights of the object, completely defines the permissions required for the execution environment of the application of the present invention. In addition, by setting the capability word of the task, a mandatory security policy can be defined, thereby solving the sandbox problem of the code. When the program corresponding to the present invention is actually running, the task is set to contain only the capability words it needs, which can achieve the operational security of the Internet of Things operating system.

[0070] Furthermore, it should be noted that the present invention can use PendSV interrupt to complete task switching: the code that triggers PendSV interrupt is embedded in each interrupt processing function, including systick (ktimer) interrupt. In the pendsv_handler interrupt processing function, the time difference before and after the schedule_in_irq() function call is obtained to calculate the time of task switching.

[0071] Furthermore, the present invention can realize fast task switching. When the system is not loaded, the minimum switching time is 6us, the maximum switching time is 14us, and the average switching time is 6.67us. When the system is fully loaded, the minimum switching time is 9us, the maximum switching time is 16us, and the average switching time is 9.35us.

[0072] Furthermore, the present invention can achieve a fast response to interrupts. When unloaded, the minimum response time is 6us, the maximum response time is 10us, and the average response time is 7.70us. When fully loaded, the minimum response time is 8us, the maximum response time is 14us, and the average switching time is 10.40us.

[0073] The above are only preferred embodiments of the present invention, and are not intended to limit the implementation methods and protection scope of the present invention. Those skilled in the art should be aware that all solutions obtained by equivalent substitutions and obvious changes made using the description and illustrations of the present invention should be included in the protection scope of the present invention.

Claims

1. A microkernel optimization method for an Internet of Things operating system, characterized in that: A plurality of IoT devices and server devices are provided in the IoT, and the IoT operating system is applied to each of the IoT devices and the server devices; The microkernel optimization method includes a system interface merging method, specifically including: In the Internet of Things operating system, a first system interface responsible for sending information and a second system interface responsible for receiving information are associated with the same thread, so that during one communication between the Internet of Things device and the server device, the Internet of Things operating system at each end only executes two system calls; It also includes a thread lock release process, which specifically includes: Step B1, during the operation of a first thread having a thread lock, the IoT operating system receives a thread lock acquisition request of a second thread; Step B2, the IoT operating system determines whether the second thread meets a preset thread lock preemption standard: When the second thread meets the thread lock preemption standard, the IoT operating system transfers the thread lock from the first thread to the second thread, and then returns to step B1; When the second thread does not meet the thread lock preemption standard, the IoT operating system moves the second thread to the top of a helper thread stack and keeps the second thread always in a ready state; Step B3, the Internet of Things operating system transfers the thread resources of the thread at the top of the helping thread stack to the running first thread, until the first thread is executed and releases the thread lock, and then transfers the thread lock to the thread at the top of the helping thread stack.

2. According to the microkernel optimization method of the Internet of Things operating system described in claim 1, it is characterized in that: It also includes a delayed update process of a thread ready queue, specifically including: Step A1, the system scheduler of the IoT operating system traverses the system and obtains all threads that are currently ready; Step A2, the system scheduler adds all other ready threads except the currently executing threads to the thread ready queue; Step A3: When the system scheduler traverses the thread ready queue next time, the unready thread is deleted from the thread ready queue.

3. According to the microkernel optimization method of the Internet of Things operating system described in claim 1, it is characterized in that: It also includes the process of specifying thread calls, including: After completing the task of sending data using a first type of thread, the system scheduler of the IoT operating system directly designates the next thread to be scheduled as a second type of thread, which corresponds to the first type of thread and is used to perform the task of receiving data.

4. The microkernel optimization method of an Internet of Things operating system according to claim 1, characterized in that: In the step B2, the preset thread lock preemption standard is: the priority of the second thread is greater than or equal to the priority of the first thread.

5. The microkernel optimization method of an Internet of Things operating system according to claim 1, characterized in that: In step B3, the thread resources include the scheduling context, time slice and priority of the thread.

6. According to the microkernel optimization method of the Internet of Things operating system described in claim 1, it is characterized in that: A capability word list including capability words for indicating different permissions is pre-set in the IoT operating system, and the IoT operating system pre-assigns different capability words in the capability word list to different threads, and the capability words are respectively stored in a storage space; An object address space is set in the memory space of the IoT operating system, and a plurality of indirect pointing objects are set in the object address space, each of the indirect pointing objects points to a different capability word; The microkernel optimization method further includes a capability delegation process, which specifically includes: The indirect pointing object is set to point to one of the capability words, and the indirect pointing object is assigned to one of the threads, thereby delegating the pointed capability word to the thread.

7. The microkernel optimization method of an Internet of Things operating system according to claim 6, characterized in that: It also includes a process of revoking the authorization of the power word, which specifically includes: The indirect pointing object assigned to the thread is set to point to a null object, thereby revoking the capability word delegated to the thread.

Images