METHOD AND APPARATUS FOR OPERATING SYSTEM KERNEL OPERATIONS

Abstract: A computer-implemented thread is provided for communicating with other threads in a set-top box environment. The thread includes a stack, a thread control block, and a queue object. The thread's stack provides data storage for the thread, and the thread control block is utilized for storing context information related to the thread. The queue object is utilized for providing communications between the thread and another thread. A swap type detector can be provided for detecting a predetermined swap type for when the thread is swapped from the CPU. A register recorder partially stores the CPU state of the thread based upon the detected swap type of the thread. The register recorder also can perform a partial storage of the CPU state of the thread based upon a received interrupt service request.

Description: METHOD AND APPARATUS FOR OPERATING SYSTEM KERNEL OPERATIONS BACKGROUND AND SUMMARY OF THE INVENTION The present invention relates generally to television set-top boxes and more particularly to computer-implemented kernel operations in a set-top box television environment. The set-top box television environment is a real-time environment which requires operations to be performed quickly. In the set-top box environment, computer-implemented threads execute upon a central processing unit (CPU) in order to perform many functions for the set-top box, such as, but not limited to, providing video and audio to an user. In such an environment, threads should optimize the time required for their functions to be achieved. The present invention is directed to this need and other needs of a set-top box environment. In accordance with the teachings of the present invention, a computer- implemented thread is provided for communicating with other threads in a set-top box environment. The thread includes a stack, a thread control block, and a queue object. The thread's stack provides data storage for the thread, and the thread control block is utilized for storing context information related to the thread. The queue object is utilized for providing communications between the thread and another thread. In another embodiment of the present invention, a computer-implemented apparatus is provided for swapping threads within a central processing unit (CPU) in a set-top box environment. A first thread is utilized for executing within the CPU and is able to be swapped with respect to the CPU. The first thread has a CPU state. A swap type detector is provided for detecting a predetermined swap type for when the first thread is swapped from the CPU. A register recorder which is connected to the swap type detector is provided for partially storing the CPU state of the first thread based upon the detected predetermined swap type of the first thread. In still another embodiment, the present invention includes a computer-implemented apparatus for swapping threads within a CPU in a set-top box environment. A first thread is utilized for executing within the CPU and is able to be swapped with respect to the CPU. The first thread has a CPU state. A kernel is provided for receiving an interrupt service request. A register recorder which is connected to the kernel performs a partial storage of the CPU state of the first thread based upon the received interrupt service request. BRIEF DESCRIPTION OF THE DRAWINGS Additional advantages and features of the present invention will become apparent from the subsequent description and the appended claims taken in conjunction with the accompanying drawings wherein the same referenced numeral indicates the same components: Figure 1 is a perspective view of a set-top box system; Figure 2 is a block diagram depicting the various exemplary programs operating within the set-top box system of Figure 1 ; Figure 3 is a block diagram depicting communication between two thread objects; Figure 4 is a flow chart depicting the operational steps for providing communications between two threads according to the teachings of the present invention; Figure 5 is a block diagram depicting the recording of the CPU state based upon swap type; Figure 6 is a flow chart depicting the operational steps utilized in recording the CPU state based upon swap type; Figure 7 is a block diagram depicting the components of the present invention for saving the CPU state in the situation of an interrupt service request; Figure 8 is a flow chart depicting the operational steps utilized by the present invention in order to save the CPU state in the situation of an interrupt service request; and Figure 9 is a block diagram depicting communication between two thread objects wherein at least one of the objects includes a clock. DESCRIPTION OF THE PREFERRED EMBODIMENT Figure 1 shows an exemplary set-top box 20 connected to television 24 via cable 28. Cable 32 provides set-top box 20 with a broadcast analog, broadcast digital, and interactive digital transmission. Set-top box 20 contains application and operating system software in order to provide an advanced interactive television environment. The operating system is utilized by set-top box 20 to, for example, provide interfaces between the application software and the various devices used by the set-top box 20. Figure 2 depicts the software components of a set-top box. The multitasking operating system of the set-top box addresses the high-performance demands of media- centric, real-time applications being delivered through a set-top box. The operating system provides an open, scalable platform for developing and delivering multimedia content to consumers across broadcast and client/server networks. The software architecture for the operating system includes layers of interconnected modules designed to minimize redundancy and optimize multimedia processing in an interactive, network setting. The layers of the architecture include a hardware abstraction layer 40, a core layer 42, an application support layer 44 and an application layer 46. Each hardware device associated with the multimedia client is abstracted into a software device module that resides in the hardware abstraction layer 40. Each of these device modules is responsible for media delivery and manipulation between a hardware device and the remainder of the operating system. Application program interfaces (APIs) supported by each device module separate the hardware dependencies of each device from the portable operating system facilities, and thereby mask the idiosyncrasies of different hardware implementations. A kernel 48 and memory manager 50 residing in the core layer 42 provide the base functionality needed to support an application. A fully preemptive, multithreaded, multitasking kernel is designed to optimize both set-top memory footprint and processing speed. Since the operating system resides on consumer units, it has been designed to exist in a ROM-based system with a very small footprint (e.g., 1 megabyte). In addition, the kernel has also been created to take advantage of 32-bit Reduced Instruction Set Computer (RISC) processors which enable high-speed transmission, manipulation and display of complex media types. Within the field of the present invention, a process is an entity which owns system resources assigned to the process. A thread is a unit of work or string of instructions to be executed. A process can have more than one thread and in such a case is considered "multithreaded." Memory manager 50 provides an efficient allocation scheme to enable the best performance from limited memory resources. Memory manager 50 provides an efficient memory allocation scheme, enabling optimal performance from limited set-top memory resources. The core layer 42 provides an integrated event system 52 and a standard set of ANSI C utility functions. Built on top of the core layer 42 is an application support layer 44. This set of support modules provides higher-level processing functions and application services. Application management, session management, and tuner management are a few examples of these services. At the highest application level 46, at least one application, referred to as a resident application is usually always executing on a set-top box. The application level 46 also provides the necessary capabilities for authoring applications and for managing resources (e.g., the tuner) between the resident application and other background applications residing on the set-top box. With reference to Figure 3, a first thread object 100 is to communicate with a second thread object 102. First thread object 100 includes within its structure a queue object 104 in order to communicate with second thread object 102. In the preferred embodiment, first thread object 100 inherits from a queue object so that whenever the thread is launched, the thread can be used as a queue. In the situation where one thread launches another thread, the creating thread has a pointer to the thread which is used for communication with that thread. Thus, the present invention allows, but is not limited to, a thread being specified instead of a queue. Preferably, the queue object structure includes two-event pointers. A queue can also be itself a thread. Within the preferred embodiment, the programming language C was used to create the structure of first thread object 100. However, it should be understood that the present invention is not limited only to implementations in C but includes implementations in such other languages as C++ or Java or other programming languages which provide for structures. Queue object 104 is included directly within the structure of first thread object 100 which is in contrast to previous approaches whose threads include pointers to queues in order to effect interthread communication and which require several memory allocations in order to create a thread and a queue by which the thread can communicate. Such previous approaches include, for example, but not limited to, the situation where a parent thread launches a thread and then creates a queue that could be used for that thread to communicate; the parent thread in such approaches would typically pass a pointer to the thread so that the thread can use the queue. Moreover, first thread object 100 includes within its structure a stack 108 and a thread control block 110. Thread identifier 106 provides an unique identifier for first thread object 100, such as an integer or a string name, so that communication can be effected with second thread object 102 in order to communicate such items as, but not limited to, events and event data. The identifier is preferably unique within a thread's process. Stack 108 is used by the thread in order to perform data storage functions while the thread operates. Thread control block 110 is utilized to store information concerning various kernel time measurements such as, but not limited to, how much CPU time a thread has consumed. With the novel structure of first thread object 100, the present invention expends less time to launch/create a thread since the components 112 are placed in a single object (i.e., first thread object 100) instead of multiple objects. Accordingly, the present invention creates components 112 during the creation of first thread object 100 by a single memory allocation. One non-limiting advantage of the present invention is that time and resources are efficiently expended since the present invention has to only perform a single memory allocation instead of multiple memory allocations. By having a thread essentially be usable as a queue, the difficulty of how one thread is to communicate with another thread has been substantially reduced since one thread communicates with the other thread by sending events directly to that other thread. Essentially, threads have inherently built into them the ability to communicate. Moreover, In the preferred embodiment, the threads operate within a set-top box environment which does not include a memory management unit (MMU). Figure 4 is a flow chart depicting the steps for communication between threads according to the teachings of the present invention. Start indication block 130 indicates that process block 134 is to be executed. Process block 134 creates a thread via one memory allocation. Within the creation operation of process block 134, a queue, a stack, and a thread control block are also created. Process block 138 sends a message to the newly created thread via the created thread's queue. The sender of such a message includes, but is not limited to, a parent thread which was the object responsible for creation of the thread via process block 134. Processing terminates at end block 142. Due to the real-time aspects and resource constraints of a television set-top box, the present invention provides for resource and time efficiencies by detecting the type of swap that a thread undergoes with respect to a CPU. In a real-time operating system, a preemption of a thread may occur between any two machine instructions. This context switch prompts a full save of the state of the CPU. As one non-limiting example, this full save on a 32-bit RISC CPU involves approximately 200 bytes of data. But when a thread yields to wait for an event, the thread does so voluntarily by making a kernel service request. In the preferred embodiment of the present invention, the kernel is aware of the cooperative nature of the call and recognizes the register volatility behavior of both the API standards used by the assembler and the C/C++ compiler used to build the operating system. As shown in Figure 3, the present invention utilizes these characteristics so that the amount of data which is saved in a swap, such as a cooperative thread switch, is reduced to, for example (but not limited to), 100 bytes. Moreover, within the field of the present invention, the term "cooperative swap" includes, but is not limited to, when one thread waits on a queue for an event delivery and will yield on its own accord. With reference to Figure 5, first thread 100 operates within CPU 160. After first thread 100 is finished executing, first thread 100 is waiting for typically an event to be delivered to a queue with instructions for what first thread 100 should do next. For example, but not limited to, first thread 100 may be an audio-related thread with its primary function to receive events that indicate how first thread 100 is to process audio data. In this example, with the buffer for first thread almost empty, first thread finishes processing audio data so that the audio player has data to play for the next 100 milliseconds. In this situation, first thread 100 waits until it receives another event containing more audio data to process. Thereupon, first thread 100 is swapped out of CPU 160 in a cooperative fashion. For example, but not limited to, first thread 100 is swapped out so that second thread 102 can execute. In a preferred embodiment, when first thread 100 is swapped out cooperatively, it is done so by utilizing a C programming language calling convention 164 which specifies which registers are non volatile registers 168 and which registers are volatile registers 172. For reference to the C programming language calling convention, please refer to the following source: the Application Binary Interface (ABI) specification contained in the Sparc Architecture version 8.0 manual published by Sparc International in California. Non- volatile registers 168 are registers which have its data preserved since these types of registers belong to a caller software program and not to first thread 100. Volatile registers 172 are registers which are allowed to be overwritten with new data. In a cooperative swap, the present invention recognizes that to effectively save the CPU state 176 of first thread 100 only the volatile registers 172 need to be saved. Accordingly, swap type detector 180 is used to detect what type of swap has occurred. In the preferred embodiment, a cooperative swap detector 184 detects when a cooperative swap has been effected with respect to first thread 100. Upon such a detection, register recorder 188 performs a partial save of the CPU state 176 of first thread 100 by saving volatile registers 172. If first thread 100 is swapped out of CPU 160 in a manner which requires the saving of the nonvolatile registers 168, then register recorder 188 performs a complete save wherein the non- volatile registers 168 are saved in addition to volatile registers 172. Such a situation where all registers need to be saved includes an interrupt service routine that awakens a higher priority thread. It is to be understood, however, that the present invention is not limited to only a cooperative swap, but also includes such other swaps as asynchronous swaps (e.g., those triggered by external events). In this respect, swap type detector 180 can detect other types of swaps which do not require the saving of the non- volatile registers 168. Thus, the present invention operates relatively more quickly since not all of the registers have to be saved in order to save the CPU state of first thread 100. Moreover, other non-limiting advantages include the efficiencies in time and resources in reloading only the data of a partial number of the registers upon first thread 100 being swapped back into CPU 160. Figure 6 is a flow chart depicting the operational steps associated with the diagram of Figure 5. With reference to Figure 6, start indication block 200 indicates that process block 204 is to be executed. At process block 204, a first thread is executed, and at block 208, first thread is to be swapped out so that a second thread can be loaded into the CPU of the set-top box. Decision block 212 inquires whether first thread is to be cooperatively swapped out of the CPU. If decision block 212 determines that it is not to be swapped out in such a manner, then process block 216 is executed wherein all of the registers are saved before processing for the present invention terminates at end block 220. However, if decision block 212 determines that first thread is to be cooperatively swapped out of the CPU, then processing continues at process block 224 wherein the volatile registers are saved. Process block 220 swaps in the second thread, and process block 232 executes second thread. Process block 236 swaps out the second thread before process block 240 swaps in the first thread back into the CPU. Processing terminates at end block 220. The present invention also optimizes the timing and the limited resources of a set- top box environment by handling interrupt service requests in the following manner. With reference to Figure 7, when first thread 100 is preempted by an interrupt service request 250, a certain amount of CPU state 176 should be saved. At the time of the preemption, the present invention saves the minimal CPU state 176 required for an interrupt service routine 252 to execute. In the preferred embodiment, the minimal CPU state needed to be saved is on the order of 70 bytes. However, the present invention is not limited to the need to save only this amount, but includes greater or lesser amounts depending upon the particular application at hand. The present invention defers the saving of the remaining portion of the CPU state 176 by providing a register recorder 188 which performs only a partial save of the CPU state 176. If, after the kernel 190 has serviced the interrupt and the interrupt service routine 252 has completed and first thread 100 is to resume execution, then the partially saved CPU state is loaded back into the registers 254 by register recorder 188. In the preferred embodiment, the present invention determines whether first thread 100 is to execute again by preferably determining if no higher priority thread is to execute. However, if a different thread is to resume execution such as second thread 102, then register recorder 188 performs a complete save of the CPU state 176 of first thread 100. The present invention by following this approach achieves such an advantage, but not limited to, as not having to consume the time and resources to perform a complete save of the CPU state of the first thread when the first thread is to resume execution after the interrupt service routine has completed. In the preferred embodiment, this advantage amounts to saving the time and resources for saving and reloading 130 bytes. Figure 8 is a flow chart describing the operational steps associated with the components of Figure 7. With reference to Figure 8, start indication block 300 indicates that process block 304 is to be processed wherein a first thread is executed. At process block 308, a user depresses a channel change key (for example on a TV remote) in order to change the channel which the user is currently viewing on the set-top box television. Such an action generates an interrupt service request at process block 312. Process block 316 performs a partial save of the CPU state of the first thread. The kernel services the interrupt service request via execution of an interrupt service routine at process block 320. After the interrupt service routine has completed at process block 324, decision block 328 inquires whether first thread is to execute. If first thread is to execute again, process block 322 loads the partially saved CPU state of first thread. Process block 336 executes first thread before processing terminates at end block 340. If decision block 328 determines that first thread is not to execute after the interrupt service routine has completed, then processing continues at process block 342 wherein a complete save for the CPU state of the first thread is performed. At process block 344, a second thread is executed before processing terminates at end block 340. Figure 9 is a block diagram which depicts clock/time operations of the present invention. The present invention utilizes a clock-T 390 which starts at the moment of boot and is usually never stopped. Preferably, values of clock-T 390 utilize a 64-bit integer, but may also be utilized as a 32-bit integer or any other format suitable for the situation at hand. Moreover, the present invention also utilizes a time-T 392 which is typically in units of seconds and is based upon a platform dependent referenced date. In addition to these clocks, a thread of the present invention also includes clock 400 that runs when the thread is running. Each interrupt service routine also has a clock that likewise runs only when the interrupt service routine is active. For example, first thread object 100 in an alternate embodiment includes clock 400 for performing such time operations related to first thread object 100, such as, but not limited to, a last run time 404 and an accumulated run time 408. Accumulated run time 408 increments time only when first thread object 100 is running. Accordingly, different types of thread performance metrics can be determined based preferably on how many events the thread has processed divided by accumulated run time 408. Moreover, the present invention is efficient in that this is performed when a thread swaps in or out as shown for example via swapping event 412. When first thread object 100 swaps out, the time for that thread is fixed. The present invention also includes last run time 404 which represents the last time first thread object was swapped either in or out depending on whether the thread was running. Accumulated run time 408 is utilized by the present invention to determine how many cycles is first thread object 100 into a current session which can be determined in the following non-limiting fashion: the current time is subtracted against the last swap time. This type of information is useful in the present invention for determining whether to modify the priority 416 of first thread object 100 where priority is indicative of an execution priority level. For example, MPEG packets can be received and which take 75 milliseconds to process each one. However, based upon the determinations of clock 400, it is determined that each of the packets is receiving on an average of 60 milliseconds of run time per packet. In such a situation, the present invention sends a modification to priority instruction to first thread object 100 in order to make priority 416 a higher priority so that there will be more time to process each MPEG packet. The present invention also includes in an alternate embodiment the ability of first thread object 100 to modify internally priority 416 based upon operations of clock 400. The embodiments which have been set forth above were for the purpose of illustration and were not intended to limit the invention. It will be appreciated by those skilled in the art that various changes and modifications may be made to the embodiments discussed in the specification without departing from the spirit and scope of the invention as defined by the appended claims.

Claims: IT IS CLAIMED: 1. A computer-implemented thread for communicating with other threads in a set-top box environment, comprising: a stack for providing data storage for said thread; a thread control block for storing context information related to said thread; and a queue object for providing communications between said thread and another thread. 2. The computer-implemented thread of Claim 1 wherein said thread is created with a single memory allocation, said queue object being created via said single memory allocation. 3. The computer-implemented thread of Claim 1 further comprising: a first thread object containing said stack and said thread control block and said queue object, wherein a second thread communicates with said first thread object via said queue object of said first thread object. 4. The computer-implemented thread of Claim 1 further comprising: a second thread launching said computer-implemented thread with one memory allocation with said set-top box environment. 5. The computer-implemented thread of Claim 1 wherein said thread control block stores measurement data related to said thread. 6. The computer-implemented thread of Claim 1 wherein said set-top box environment is exclusive of a memory management unit for managing memory allocations for threads operating in said set-top box environment. 7. The computer- implemented thread of Claim 1 further comprising : a clock for performing time operations related to operations of said thread. 8. The computer-implemented thread of Claim 1 further comprising: a clock which indicates last run time of said thread. 9. The computer-implemented thread of Claim 1 further comprising: a clock which indicates accumulated run time of said thread. 10. The computer-implemented thread of Claim 1 further comprising: a clock which indicates accumulated run time of said thread, said accumulated run time being used to determine amount of processing said thread has undergone. 11. The computer- implemented thread of Claim 1 further comprising: a priority level indicative of execution priority level. a clock which indicates accumulated run time of said thread, said accumulated run time being used to modify said priority level of said thread. 12. A computer-implemented apparatus for swapping threads within a central processing unit (CPU) in a set-top box environment, said CPU being connected to registers, comprising: a first thread for executing within said CPU and able to be swapped with respect to said CPU, said first thread having a CPU state; a swap type detector for detecting a predetermined swap type of said first thread from said CPU; and a register recorder connected to said swap type detector for partially storing said CPU state of said first thread based upon said detected predetermined swap type of said first thread. 13. The computer-implemented apparatus of Claim 12 further comprising: a cooperative swap detector for detecting a cooperative swap type of said first thread from said CPU, said register recorder being connected to said cooperative swap type detector for partially storing said CPU state of said first thread based upon said detected cooperative swap type of said first thread. 14. The computer-implemented apparatus of Claim 13 wherein said cooperative swap detector detects said cooperative swap type of said first thread from said CPU based upon a programming language calling convention. 15. The computer-implemented apparatus of Claim 13 wherein said cooperative swap detector detects said cooperative swap type of said first thread from said CPU based upon a C programming language calling convention. 16. The computer-implemented apparatus of Claim 12 further comprising: a cooperative swap detector for detecting a cooperative swap type of said first thread from said CPU, said register recorder being connected to said cooperative swap type detector for partially storing said CPU state of said first thread based upon said detected cooperative swap type of said first thread, said register recorder completely storing said CPU state of said first thread when the swap type of said first thread is not a cooperative swap type. 17. The computer-implemented apparatus of Claim 12 wherein said CPU state includes the state of the registers related to said first thread. 18. The computer-implemented apparatus of Claim 12 wherein said registers include volatile and non-volatile registers, said register recorder storing said volatile registers related to said first thread based upon said detected predetermined swap type of said first thread. 19. The computer-implemented apparatus of Claim 18 wherein said register recorder does not store said non-volatile registers related to said first thread based upon said detected predetermined swap type of said first thread. 20. The computer- implemented apparatus of Claim 19 wherein said predetermined swap type is a cooperative swap type. 21. The computer-implemented apparatus of Claim 20 further comprising: a second thread for executing after said first thread is swapped from said CPU. 22. The computer-implemented thread of Claim 12 wherein said set-top box environment is exclusive of a memory management unit for managing memory allocations for threads executing in said set-top box environment. 23. A computer-implemented apparatus for swapping threads within a central processing unit (CPU) in a set-top box environment, said CPU being connected to registers, comprising: a first thread for executing within said CPU and able to be swapped with respect to said CPU, said first thread having a CPU state; a kernel for receiving an interrupt service request; and a register recorder connected to said kernel for partially storing said CPU state of said first thread based upon said received interrupt service request. 24. The computer-implemented apparatus of Claim 23 wherein said register recorder reloads said partially stored CPU state of said first thread based upon said interrupt service request having been completed. 25. The computer-implemented apparatus of Claim 23 wherein said register recorder performs a complete save of said CPU state of said first thread based upon a second thread being executed after said interrupt service request has been completed. 26. The computer-implemented apparatus of Claim 23 wherein said CPU state includes the state of the registers related to said first thread. 27. The computer-implemented apparatus of Claim 23 wherein said set- top box environment is exclusive of a memory management unit for managing memory allocations for threads executing in said set-top box environment. 28. The computer-implemented apparatus of Claim 23 further comprising: a swap type detector for detecting a predetermined swap type of said first thread from said CPU, said register recorder being connected to said swap type detector for partially storing said CPU state of said first thread based upon said detected predetermined swap type of said first thread. 29. The computer-implemented apparatus of Claim 2 further comprising: a cooperative swap detector for detecting a cooperative swap type of said first thread from said CPU, said register recorder being connected to said cooperative swap type detector for partially storing said CPU state of said first thread based upon said detected cooperative swap type of said first thread. 30. The computer-implemented apparatus of Claim 28 wherein said first thread is an object whose structure includes: a stack for providing data storage for said first thread; a thread control block for storing context information related to said first thread; and a queue object for providing communications between said first thread and another thread.

Inventors: HOUHA JAMES A, HOUHA, JAMES, A.
Applicants: POWERTV INC, POWERTV, INC.
Application year: 1999
Main classification: H04N5
IPC codes: G06F9, H04N5