A method of operating a computing device trough the use of extensible thread states

Abstract

A personality layer running on top of an operating system kernel puts any thread that the personality layer is responsible for into a new state unknown to the kernel. This prevents the kernel from performing operations on threads that have been set to be in one of these new states, where these operations are sensitive to the state of the thread itself (eg, cancel, suspend, change priority). Instead, the kernel redirects these thread operations to a handler in that personality layer, which then handles the operation. So essentially, the kernel can be extended by using added layers of personality so it can be used to run native real-time applications written for other real-time operating systems.

Description

technical field [0001] The present invention relates to a method of operating a computing device, and more particularly to utilizing an extended range of thread states in an operating system (OS) kernel to add a new personality layer to the device. Background technique [0002] This is of great benefit to manufacturers and others trying to implement existing computing technology on new platforms to re-use their existing software assets. This is especially important for user devices such as mobile phones that have a short product life relative to the time invested in product development; anything that shortens the development cycle, improves development efficiency, and reduces overall device cost can be used. [0003] Communications stacks and protocol implementations are good examples of software stuff that manufacturers try to reuse in modern consumer electronics devices. There is a growing trend towards the convergence of such devices, whereby communication and networking...

AI Technical Summary

Problems solved by technology

[0010] However, this approach also has some disadvantages: most notably the cost of an additional processor and the increase in physical memory required in the device

[0014] However, this second option also has its problems

performance degradation due to exception branches called on every interrupt and every execution call (even if they are not related to LRTA)

Hypervisor systems degrade performance even more due to more exception branches and a whole extra layer of processing on interrupts

Additionally, these exception branches add additional complexity and risk of bugs to particularly sensitive areas of the code

Moreover, since low-priority threads in the LRTA will take precedence over high-priority threads in the native OS, inserting exception branches into the native OS kernel to allow the RTOS to run at any time will destroy its real-time performance

Hypervisor systems don't have to face this kind of problem, but are more complex and result in a larger performance penalty

Also, when more than one RTOS needs to be integrated on the device, exception branching can become extremely complex and unmanageable; for example, if both a GSM signaling stack and a Bluetooth stack are required, and each of them uses a different RTOS , it will be necessary

Images