KR19990076823A - Operating system kernel and how to filter events in it and how to implement semaphores - Google Patents

Abstract

Event filtering feature 204 that allows an improved operating system kernel for home communication terminals to allow a thread to flow in an HCT to register interest in a particular type of event from a particular source or from another desired area. It includes. Events that occur in systems 205 and 206 are prequalified by the kernel before being provided to individual threads that register interest only on certain types of events. By implementing filters in the kernel context, you can avoid thread context switches. Events occurring in the system may be matched with events of interest 200a, 200b, 200c registered by multiple threads by an efficient comparison operation including a mask field and a code field. In addition, multiple thread synchronization mechanisms, such as alerts and signals, can be implemented using a common event object that is integrated on the event queue.

Description

Operating system kernel and how to filter events and implement semaphores in it

The present invention generally provides a home communications terminal (HCT) to provide real-time operating systems suitable for high performance applications, such as cable television or other audiovisual capabilities. It's about doing things in)). In particular, the present invention is directed to providing a feature that enhances the performance of an operating system installed in a device having limited computing resources.

<Related Information>

The capabilities typically provided by conventional operating systems for HCTs, such as those of cable television systems, are limited, and within this limited capability range, users control hardware devices and have limited menus and displays. depending on the displays). The growth of the cable television industry includes interactive video games, video-on-demand, downloadable applications, higher performance graphics, multimedia applications, and more. As new capabilities are anticipated, the need to provide an operating system for HCT that can support these new capabilities has increased. In addition, the emergence of a new generation of fiber-based networks has resulted in a significant increase in the data bandwidth that can be transmitted to and from individual homes, enabling the development of completely new uses for HCT. As US federal and state laws are revised, new uses, such as telephony over existing cable networks, are foreseen. As a result, the conventional HCT and its operating system are rapidly declining. In short, HCT needs to be switched from current limited television sets to interactive multimedia entertainment and communication systems.

One possible solution to increase the capabilities of HCT is to introduce existing operating systems, such as UNIX, into HCT's PC-compatible microprocessors. However, due to the enormous size of memory requirements needed to support such existing operating systems, such solutions require almost unacceptably high costs. Since memory is an expensive component in HCT, considering the resulting price pressures, the addition of functionality should be done in such a way as to minimize the use of memory and maximize the performance of the processor. Accordingly, it is believed that new operating systems must be developed that provide media-centric high performance features while minimizing memory requirements.

A typical example of one conventional operating system configuration that is typically determined to require large amounts of memory is the operating system for thread coordination mechanisms such as semaphores, timers, exceptions, timers, exceptions, messages, etc. It is split into individual subsystems within it. Each of these subsystems typically includes different application programming interface (API) conventions, different data structures, and different memory areas, which are driven by the kernel. Are traced and inspected.

A typical example of another conventional operating system configuration that is believed to cause inefficiency in a real-time operating system is to have an event delivered to a thread running on that system. Conventional methods of delivering an event to a thread schedule the thread and even if the event is of no interest to the thread (even if the thread decides immediately after receipt of the event that event is out of interest and discards the event). This includes providing events to the thread. Thus, in this method, processing time for performing a context switch is wasted, and memory space is wasted.

As an example, when a user presses a key on the HCT keypad, the conventional kernel delivers the event to the processing thread of the event even if the event is coming because the cursor on the television screen is not located within a given window. Thus, the issue of inefficiency arises because the thread position on the screen involves a context switch to quickly determine that the event is coming and subsequent thread execution. In many other examples, this inefficiency results from the fact that a thread in the system cannot receive events by that thread in advance.

In summary, conventional operating systems used for HCT have disadvantages in terms of performance and memory that prevent their usefulness when used in new high performance graphics-intensive applications. Thus, there is a need to provide operating system features that can reduce memory requirements while improving the overall performance of applications running in connection with the operating system.

Summary of the Invention

In the present invention, the above-mentioned problem is solved by providing an efficient real-time kernel having a feature adapted to the needs of the HCT application. Conventional kernels typically provide separate event subsystems, semaphore subsystems, and queue subsystems, while in one embodiment of the present invention, these subsystems can be configured via semaphores and other synchronization mechanisms through events on the event queue. It is being replaced by a single integrated event subsystem that provides the functionality of. In addition, instead of using different data structures to provide the different services described above, a single event data structure may be used in this embodiment. In addition, in this embodiment, a single data structure can be optimized to speed up the kernel. Also, in this embodiment the kernel only needs to know two states for each thread (running a thread or waiting for an event for delivery to a thread), thereby improving kernel efficiency. In contrast, conventional kernels typically require the kernel to distinguish between various states, such as semaphore waits, events, message streams, or I / O operations, which increases complexity in the kernel and increases memory requirements. do.

In another embodiment of the present invention, each thread is provided with means for registering with the kernel to indicate the type of event (type of event) the thread wishes to receive. Each thread also specifies a "filter" procedure that determines whether the delivered event is appropriate for the context when the event is delivered to the system (but before the event is delivered to the thread). This filter can be an interrupt service routine that is executed at the time of interruption instead of calling the specified thread, in which case a context switch will be required.

As used herein, the term “home communication terminal (HCT)” refers to a terminal used in a telephone network, cable television or other audiovisual programming network, satellite network, or a combination thereof.

Other objects and advantages of the invention will be apparent from the following detailed description, drawings, and claims.

1 shows one possible configuration of a home communication terminal (HCT) in which an operating system utilizing the principles of the present invention may be installed.

FIG. 2 is a diagram schematically illustrating how the kernel event coordinator configured in accordance with the present invention effectively adjusts and filters the introduction event.

FIG. 3 illustrates the steps that a kernel event coordinator may execute to effectively coordinate events in an HCT.

4 illustrates an example of several different threads with registered interest in various types of events.

5 illustrates one possible format for an event object in a system utilizing the principles of the present invention.

6 illustrates how two threads implement semaphores by using a queue that implements NextEvent functionality by the kernel.

1 is a block diagram of a home communication terminal (HCT) in which various principles of the invention may be practiced. HCT includes CPU card 100, graphics card 101, decoder card 102, display panel and keypad 103, main processing board 104, front end 105 It may also include a tuning section 106 and an audio section 107. The principles of the present invention may be implemented using a suitable CPU 100a, such as a PowerPC or Motorola 68000, along with a suitable EPROM 100c and RAM 100b. In addition, an application program running on the CPU 100a may interact with various peripheral devices that are well known in the art, such as a mouse, a game controller, a keypad, a network interface, and the like. There will be.

2 schematically illustrates how a kernel event handler utilizing various principles of the present invention effectively coordinates incoming events and predefines events for a given thread running in the HCT. Generally speaking, different threads in the system only care about some type of event, and you want to ignore other types of events. Examples of events include keypresses on the keypad attached to the HCT, mouse movement indications received from the mouse attached to the HCT, button presses on the game controller connected to the HCT, coupled to the HCT. There is a signal indicating the beginning of the headend or movie. Examples of different threads (which may run concurrently in a multi-threaded kernel) include a copy of a video game run by a first player, a copy of a video game run by a second player, an on-screen programming guide. (on-screen programming guide), movie player, channel tuning indicator, or user interface for a customer billing application. In general, one application may correspond to a single thread, or a single application may be divided into multiple threads, which may be executed simultaneously for optimization of performance. Those skilled in the art will appreciate how various applications may be configured with a single or multiple threads in the system.

The customer billing application may only be interested in events that occur only from the HCT keypad and only when the customer first enters a particular code. Two video game threads may be interested in all keypresses occurring from any of the two game controllers coupled to the HCT (thus, copies of the same event must be delivered to those two threads). The on-screen programming guide thread may only be interested in keypress events that occur when the mouse cursor is located within any preset area on the screen, and (the keypress when the mouse cursor is not located within any preset area on the screen). You may want to ignore all other events (including events). Of course many other examples are possible. Thus, each thread may wish to register interest in several different types of events, and may later want to change the registered interest.

2 illustrates an example configuration that includes a kernel event conditioner 204 that can accomplish the above purpose. As shown in Figure 2, the two threads (A and B) use the function pk_RegisterInterest (see Appendix 1), kernel-provided programming interface to kernel attention to two different events. You can register each at. The corresponding function pk_RemoveInterest allows a thread to remove interest from a thread (see Appendix 1). In response to a call to pk_RegisterInterest, the kernel constructs an event interest list 200, which may include a linked list of "event interest" objects 200a, 200b, and 200c. For example, thread A may register an interest in an event corresponding to event interest 200b, and thread B may register an interest in an event corresponding to event interest 200c. Each of these is specified by a parameter in the corresponding function call to pk_RegisterInterest. In the example shown in FIG. 2, thread A includes a video game application that only cares about keypress events from the game controller while thread B has a billing application that only cares about button presses from the mouse. It is assumed to be included.

In various embodiments, the kernel manipulates the event list 200 in response to calls to pk_RegisterInterest and pk_RemoveInterest. When the kernel event coordinator 204 receives or occurs an event, the coordinator traverses the event watchlist 200 to determine the conditions under which the various threads of the system should be invoked. In general, by comparing an event descriptor (which describes an event) with a parameter contained within each event interest object, the kernel event coordinator 204 can determine whether or not a thread with declared interest in the event has been invoked and Effectively determine how to call.

Each event interest object 200a, 200b, and 200c has a code field, a mask field, a filter procedure field, and a queue according to the parameters described for pk_RegisterInterest. field). For example, if thread A registers interest for a game controller event, it specifies code 2, mask 2, filter 2 and cue 2 as parameters in function pk_RegisterInterest.

Reference is briefly made to Appendix 1, which contains a description of a number of functions that may be used to carry out the various principles of the invention. For each function in Appendix 1, a syntax is provided that includes a list of usage parameter types and examples. Referring to the function pk_RegisterInterest, for example, the thread (A) calls this function and supplies the parameter values for the code, masks, filters, and queues (filter and queue parameters are optional), so that the kernel can predefine events. Direct the event to thread A.

The pk_RegisterInterest function (see Appendix 1) generates event interest and registers it with the kernel. Its code parameter specifies the description of the desired event, its mask parameter specifies an event mask that further clarifies the event of interest, and its filter parameter specifies an interrupt service routine (called by the kernel when the event occurs). ISR), whose cue parameter specifies a pointer to the queue to which the event is sent.

Each event interest object, for example element 200b of FIG. 2, holds a mask and code that specifies a desired event descriptor for an introduction event. The mask specifies which fields of the event descriptor are appropriate for the specified interest, and the code specifies the values that those fields must have in order for the delivered event to trigger the event interest.

The bits of the mask field can be used to indicate which fields of the event descriptor are appropriate for a particular interest. One possible example is to assign 32 bits to the mask field. Of the 32 bits, eight bits can be allocated to indicate the device type (i.e. the type of device that generated the event), and the other eight bits represent the device case (i.e. the case of the device type that caused the event). Another eight bits may be allocated to indicate the type of event (i.e., the type of event where the device occurred, e.g. keypress), and another eight bits may be assigned to the event data (i.e. A small amount of data that may contain information, for example a particular key pressed. This assignment is merely an example and is not intended to be limiting.

For example, as shown by the event descriptor 201 in FIG. 2, corresponding fields may be included in each event descriptor. Thus, each event descriptor may include a device type, device case, event type, and event data corresponding to the event.

To register an interest in an event from a device type, the thread will set the device type parameter to all ones. Thus, the following (hex) mask may be defined.

kDt_Any OOFFFFFF Any device type (bits 24 through 31)

kDi_Any FFOOFFFF Some device examples (bits 16 to 23)

kEt_Any FFFFOOFF Any event type (bits 8 through 15)

kEd_Any FFFFFFOO Any data value (bits 0 through 7)

For example, to register all game controller events, the application

pk_Registerinterest (kDt_Controller,

kDi_Any & kEt_Any & kEd_Any, NULL, my_Q)

(Where kDt_Controller is the code corresponding to the game controller, and the event mask is incremented to FF000000 (no filter procedure is specified).

As can be seen, the mask FF000000 allows all device types to be set so that the device type is compared with the specified one in the code (ie the controller type) but the device case (the next 8 bits), the event type (following 8) Bits) or event data (the last 8 bits) is left at zero (“not caring about”). It will be appreciated that the event may be generated by a subset of the fields described above or by completely different fields that define a particular type of event.

Referring back to the example of FIG. 2, assume that thread A wants to register interest in all game controller keypress events that occur when the cursor is within a preset screen area and ignore all other types of events. Thread (A) specifies Mask 2, which specifies “device type” as a qualifier, leaves the device case open, specifies “event type” as a qualifier, and leaves “event data” open. By specifying the event interest 200b is generated. Thread A also specifies code 2 that identifies "game controller" as the desired event type and "keypress" as the desired event type. Finally, thread A specifies the filter procedure 203 to be executed to further define the event and the queue in which the event is to be placed (queue 2). In the example shown in FIG. 2, the filter procedure 203 checks the cursor position to ensure that the cursor is positioned within the confined area before passing the event. It is assumed that filter procedure 203 is run in kernel mode and thus context switching is avoided. In other words, thread A will not be scheduled by the kernel if an event does not meet all of thread A's limitations.

When an event is generated from the game controller 205, an event descriptor 201 corresponding to the characteristic of the event is generated. A device driver that detects a hardware change can deliver such an event using pk_PostEvent (see Appendix 1). In the example of FIG. 2, the "A" button on the game controller 205 is pressed, so that the event descriptor 201 sets the device type as the game controller ("1") in response to the "A" button. The example is shown as "1", the event type as "key", and the event data as "A". The kernel event coordinator 204 receives the introduction event (from pk_PostEvent) and traverses the event interest list 200 to match the introduction event to the event of interest.

In a preferred embodiment, the event matching step may be performed very effectively by multiplying the mask of each event interest object and the introduction event descriptor and then comparing the result with the code of the event interest object. If there is a match, the event is predefined. In FIG. 2, for example, the kernel event coordinator 204 first tests the event-interest object 200a and quickly determines that it does not match by multiplying the event descriptor 201 by mask 1 and comparing the result with code 1. . This "AND" and then "COMPARE" operations can be done very effectively on the CPU (typically only two assembly language instructions are needed), resulting in performance obtained by using the principles of the present invention. An improvement is added.

After determining that event descriptor 201 does not match event interest object 200a, kernel event coordinator 204 then examines event interest object 200b and multiplies mask 2 with event descriptor 201, and then Compare the result with code 2. In the example of FIG. 2, the results are assumed to match successfully. However, because thread A specifies the filter procedure 203, the kernel event coordinator 204 does not pass the event to thread A, but instead executes the filter procedure 203, and this program does not. The procedure checks the cursor position to see if it is in the valid area. If the cursor is in the valid area, the kernel event coordinator 204 forwards the event to queue 2, and thread A can extract the event from queue 2 using pk_NextEvent (see Appendix 1).

It should be noted that if the event does not pass the filter procedure 203 successfully, thread A is not scheduled, so that context switching is avoided and kernel efficiency is increased. In other words, in the preferred embodiment, the filter routine 203 is executed during execution of the kernel and does not require scheduling of thread A. If only 20% of the events are actually of interest to the thread, then the "interest" decision in the kernel code is much faster than in the thread code that requires context switching.

With continued reference to the example of FIG. 2, assume that thread B has registered interest in certain mouse movements from mouse 206. Thread B will set up event interest object 200c by pk_Registerinterest to specify the device type as a qualifier and leave the other mask fields open. For the device type of code 3, thread B will have a specified “mouse”. When the user presses the mouse button, an event descriptor 202 will be generated, which device type is mouse ("2"), device case is "1", event type is "key" and event data is "mouse". Press ”. The kernel event coordinator 204 traverses the event watch list 200, preferably multiplying each mask with an event descriptor and comparing the result with the code. When this coordinator reaches the event of interest object 200c, the coordinator will find a match and immediately place the event on queue 3, which is specified as the desired queue by thread B (any filter procedure). I'm not specific either).

3 illustrates steps that may be executed by the kernel event coordinator 204 to coordinate the introduction event of the system. The event watchlist is assumed to have already been created by using the pk_RegisterInterest call made by the system's thread. In step 301, the next event object is retrieved from the event watchlist. In step 302, the mask from the event interest object is multiplied with the event descriptor corresponding to the event. In step 303, the result is compared with the code from the event interest object. In step 304, if there is a mismatch, processing resumes for the next event interest object in step 301.

In step 304, if there is a match, it is determined in step 305 whether a filter has been specified for the event interest object. If the filter has been specified for the event interest object, then the filter specified in step 306 is preferably invoked directly by the kernel without context switching. In step 307, processing proceeds to step 308 if the event passes the filter, otherwise processing resumes for the next event interest object in step 301. In step 308, if the queue has been specified for event interest, the event is placed in the specified queue in step 309, otherwise processing resumes in step 301 until the event interest list is reached.

Note that the event can be ignored if no queue is specified. This situation may be desirable, for example, if the processing is done in the filter itself. For example, in the case of just a memory area or other type of short-term operation, it may be more efficient to do this in a filter list (kernel) and you do not need to provide any queues (i.e. any thread to wake up). none.).

In addition, the filter can be reused. For example, one filter may have the ability to determine whether the cursor is within a particular location on the screen, and different threads may specify and use that filter. For example, if three different applications, each with a separate window on the television screen, are run in the HCT and the user moves the mouse on the screen, a single filter that determines whether the cursor crosses the window boundary for the specified thread. You can think of

Also, if a filter and a queue are specified, the filter can modify the event itself. For example, the filter may modify the time of the event before placing the event on the queue. This may be used, for example, by a “replay” filter that changes the time stamp of the event to the current time (eg, converts to the current time). Another example is to check the signature of the event before the thread wakes up.

4 shows another example of applying the principles of the invention. It is assumed that the video game to be executed on the HCT provides two characters competing with each other and the two users interact with separate game controllers 401 and 402 respectively. The video game includes a main video game thread 403 and two player threads 404 and 405 that control overall scoring and game behavior. In the example of FIG. 4, for example, Player 1 thread 404 controls the behavior of the first character on the video screen, and Player 2 thread 405 controls the behavior of the second character on the video screen. Thus, thread 404 manipulates the first video character based on the action taken by player 1 and thread 405 manipulates the second video character based on the action taken by player 2. As a result, Player 1 thread 404 registers interest in all events from Game Controller # 1 (by specifying the appropriate code, mask, filter, and cue parameters) and Player 2 Thread 405 registers Game Controller #. Register interest in all events from 2.

In the configuration shown in FIG. 4, the Player 1 thread 404 wants the Player 1 thread 404 to know that Player 2 has pressed the "Stop" key on game controller # 2 and Player 1 has pressed the "Stop" key on game controller # 1. Assume that player 2 thread 405 wants to know (in other words, assume that either player, including the player operating the opposing controller, wants to stop the game). To accomplish this, player 1 thread 404 may optionally register only interest in the "stop" event from game controller # 2 and player 2 thread 405 may subscribe to the "stop" event from game controller # 1. Only interest may be selectively registered. This greatly improves efficiency because the operating system does not have to send all events from the opposing game controller to the thread. In FIG. 4, if each queue (and each corresponding thread) is provided with a copy of every event that each game controller has encountered, much more time is wasted in processing undesirable events, which wastes CPU time and memory. Performance can be significantly improved by allowing each thread to register only interest for a certain type of event so that the kernel only sends events of that type for each thread.

Similarly, assume that the main video game thread 403 is interested in registering as it receives a "game event" from each player thread. Each player receives a command from the main video game thread 403 to cause the character to disappear because of too many events, for example, a blow by another player. The foregoing registered interest is illustrated by the arrow in FIG. 4 with annotations for the registered type of event.

It is also assumed that instant replay thread 406 provides the ability to review all previous behaviors over a time window. Thus, the thread gets its own copy of each event that the controller has generated by registering interest in all events that either controller has encountered. In this way, individual threads do not have to send a "copy" of the event to each other.

As another example, on-line TV guides may cause tuning tables to be downloaded at unknown times. When a new tuning table is downloaded, it may organize events. Typically, more than one thread in an HCT may need a copy of such a tuning table. Therefore, there is a problem of determining when to free the memory used for storing the tuning table. This is accomplished by creating a filter that creates a private copy of the tuning table for each thread that registers interest in tuning table events. Thus, if all the threads did using their copy, they would destroy their copy, thus avoiding the problem of judging when the memory area could be freed.

It should be noted that a single event can trigger more than one filter and can also trigger more than one thread. For example, one thread may be an event recorder (debugger), which thread would like to get a copy of every event in the system. To accomplish this, the thread will create a mask that clears all bits, which indicate interest in any event.

Now, according to another embodiment of the present invention, how to replace thread synchronization functions such as semaphores, timers, media events, exceptions, messages, etc. with event objects and integrate them into the event queue to minimize memory requirements and application development. This will be explained in more detail.

I think the kernel handles time very accurately. The clock generates time at a very high speed (eg 25 MHz), which can be used for timing. According to various aspects of the present invention, every event in the system may include a time stamp (e.g. consisting of 64-bits), which includes a “snapshot” of the system clock. If an event is delivered or delivered, future time can be inserted into the event object (instead of the current time). The kernel does not immediately deliver the event to the specified thread, but it does not hold and deliver the event until the specified time is reached. Therefore, all events can be alarm signals. For example, every key press triggers an event at a specific time.

Instead of recording an alert procedure that detects that a time has been reached (for scheduling an event), it inserts a future time into the event object so that when the event is delivered, the event is not actually delivered to a future time in the event object. do. This eliminates the need for kernel code to implement an alarm signal that includes a status check (eg, "wait for alarm") indicating which thread is in which of the additional data structures, storage area, and several states. .

5 illustrates one possible configuration for an event object 501 in the kernel, including the next event object, code (corresponding to the event descriptor), time, X, Y, Z fields, and a “where” pointer. Illustrated. In various embodiments, the event object 501 may be comprised of 28-bytes including a "public" portion accessible by the thread and a "private" portion hidden from the thread.

An event may be integrated into an "intrusive" form, which is compared to an "extrusive" form in which the list elements are individually configured (ie, objects in the list are fields integrated into their data structures). Has a). The “where” field may include a queue pointer used for scheduled_delivery (delivering events to the queue at a later time). The thread may use pk_DeliverEvent to set code fields (device type, case, etc.) where the event is generated by the thread; Alternatively, the device may set the code field using pk_PostEvent as described above. The X, Y, and Z fields contain a “payload”; This can include any data (including pointers to data structures).

As one example, an event structure can be used for the setup of an alarm signal. The game may have a three minute round. At the end of the round, the bell will ring. The thread sets an alarm signal by calling pk_ScheduledDelivery (see Appendix 1), sets the time to 3 minutes from now, and points the event code (X, Y, Z) and the thread's own queue to the "where" pointer. Can be specified. The thread then uses pk_NextEvent to cause the next event to leave its queue. Although other API calls can be used, a single small data structure can be used, eliminating the need for a separate alert system and eliminating the need to provide specific functionality for alerts by the kernel. Note that the thread can "pre-timestamp" the object and then the kernel can reuse the same space when the actual time is stamped.

Thus, integrating the alert function into the event delivery function saves memory, processing time and programmer effort. When a thread "sleeps", the kernel does not need to determine whether the thread is waiting for a semaphore or alarm or some other type of synchronization event. Every time a thread sleeps, the operating system always waits for events on its queue. This also makes the kernel smaller. In contrast, in the conventional kernel, it is necessary to execute an instruction for determining whether a thread is waiting for an alarm, semaphore, queue wait, message wait, or the like.

A second example of integration includes a semaphore (FIG. 6). Assume that two threads 602 and 603 require the use of a single printer. The conventional solution is to provide semaphores in which two threads respond (ie, those threads are in a “semaphore wait” state, and the kernel is a “semaphore wait” with a semaphore wait data structure). Put a thread on the queue).

In contrast to conventional methods, the present invention contemplates the use of an event object. To implement a semaphore using an event queue, create a queue 604 (typically by printer driver 601) and place a single event 604a on that queue. A first thread 602 that needs a resource (eg, a printer) creates a call to pk_NextEvent (see Appendix 1) to specify a printer semaphore queue 604. This feature causes the thread to wait when there are no events on the queue, and extracts events when there are events on the queue. Thus, assuming that an object is still on the queue, kernel 605 removes the object from queue 604 and delivers the event to thread 602. If another thread 603 tries to use the resource (by calling pk_NextEvent), that thread will wait until event 604a is returned to queue 604 by first thread 602. When the first thread 602 finishes using the resource, it calls pk_ReturnEvent (see Appendix 1) which returns an event to the queue 604 so that the second thread 603 can finally execute its pk_NextEvent function. do.

Thus, in a preferred embodiment, the kernel 605 does not place the second thread 603 in "waiting for semaphore" or "waiting for alarm" or any other type of mode; Instead, typical examples of common events are used. This improves the kernel's efficiency, because the kernel does not have to maintain separate queues for all types of different activities and the thread is only in one state when testing the state of the thread. This is because the kernel already knows it can be. In addition, the same general event object can be used to implement semaphores of the system; There is no need to specify any specific semaphore data.

The above example can be extended to multiple resources. For example, in FIG. 6, if there is a second printer 606 (but potentially three or more threads that may need to use two printers), each printer will send an event on the queue 604. May; The first two threads that call pk_NextEvent will use the printer, and the third calling thread will be waiting for events by the kernel. Therefore, no pre-set limit needs to be specified for the number of semaphores; Another advantage is that the queue can be enlarged as needed. Thus, you can use events for anything; Even the kernel does not need to know the "semaphore" synchronization mechanism.

To eliminate redundancy and simplify the event system, all of the following types of coordination mechanisms can be categorized as events and implemented using features such as those shown in Appendix 1.

-Thread synchronization, including semaphores, messages, and queue messages, all passed between threads as synchronization objects

-Demand scheduling, indicating that a request has been made to upgrade the priority of a thread.

-Timer events and delayed actions (events can be delivered immediately or at a specified future time)

Inter-thread exception handling (events can occur whenever a thread throws an exception)

User interface actions such as pressing a button on a remote or game controller, changing volume, moving the pointer device, etc.

-Media events such as initiating audio playback, reaching the end of movement, inserting media into the device, or ejecting the media from the device

-Application-specific events (user-defined events)

Many modifications and variations of the present invention are possible, with reference to specific values as examples only. For example, although reference is made herein to "threads," such terms are to be understood as including processes, tasks or other entities that may be scheduled by the operating system. As another example, an application programming interface for performing various functions such as registering interest in an event is described, but the same function may be implemented using an equivalent mechanism. Also, specific function names are mentioned by way of example only. Thus, it will be apparent to one skilled in the art that the present invention may be practiced otherwise than as described above within the scope of the claims.

Claims (18)

An operating system kernel (HCT) to run on a home communication terminal (HCT) where a plurality of different events can occur and a plurality of different threads can run. operating system kernel), Each of the different multiple threads may register interest in one of the different multiple events by specifying parameters which indicate qualifications for the one event of interest. An event registering function; A data structure including a list of event objects each including a specific one or more parameters using the event registration function; In response to receiving an event descriptor corresponding to one of the different multiple events, traversing the data structure and comparing the event descriptor with one or more parameters in each of the event objects, wherein the event descriptor is An event handler that provides at least a portion of the event descriptor to a thread that has a registered interest in the event in response to determining that it matches one or more parameters in a particular event object of the event objects. Operating system kernel comprising a. The method of claim 1, The event object includes at least two parameters, including a first parameter including a code field and a second parameter including a mask field, the mask field being a plurality of parameters within the event descriptor. Operating system kernel, which indicates which of the fields is appropriate, and wherein the code field represents a value that must match each suitable field in the event descriptor. The method of claim 2, The event coordinator multiplies the mask field with at least a portion of the event descriptor and compares the multiplication result with the code field for comparison. The method of claim 3, wherein And the event handler places at least a portion of the event descriptor on a specified queue in the event object. The method of claim 1, Wherein the one or more parameters indicate a device type and an event type to be defined. The method of claim 1, Wherein said at least one parameter is indicative of a data value representing a key press from a device coupled to the respective HCT. The method of claim 1, Wherein said at least one parameter comprises a filter to be executed by said event coordinator to further define said event descriptor. The method of claim 7, wherein And the filter is executed in conjunction with the kernel rather than in association with a thread. The method of claim 7, wherein The filter checks the position of the cursor with reference to a window to further define the event. The method of claim 7, wherein The event coordinator compares the event descriptor with one or more parameters in each of the event objects, and in response to determining that the event descriptor matches one or more parameters in a particular event object of the event objects, the one event Operating the filter before providing at least a portion of the event descriptor to a thread having a registered interest in the operating system kernel. The method of claim 1, And an event registration function that allows each of the different plurality of threads to remove previously registered event interest. A method of filtering events in an operating system kernel for running on a multi-threaded home communication terminal, (1) registering a interest in one or more events from one of the plurality of threads by creating a data structure that includes one or more parameters that limit the types of events to be provided to the thread of interest; (2) detecting that an event has occurred in the system and in response generating an event descriptor describing the details of the event; (3) in the operating system kernel, compare the event descriptor generated in step (2) with the one or more parameters in the data structure created in step (1), wherein the event descriptor matches the event. Providing at least a portion of the event descriptor to a thread corresponding to the data structure in response to the determination. Event filtering method in the operating system kernel, characterized in that it comprises a. The method of claim 12, The step (1) comprises generating a data structure comprising a code field and a mask field, the mask field indicating which portions of the event descriptor are suitable for comparison of the step (3), the code field Indicates a value that must match each suitable portion in the event descriptor. The method of claim 12, Wherein said step (1) comprises using parameters indicative of a device type and an event type to be defined. The method of claim 12, The step (1) includes specifying a filter to be executed by the kernel to further define the event descriptor, wherein the step (3) includes specifying the filter before providing at least a portion of the event descriptor to the thread. And a step of executing a filter. The method of claim 15, And said step (3) comprises executing a transforming filter before providing at least a portion of said event descriptor to said thread. A method for implementing semaphore functionality on a home communication terminal (HCT) using an operating system kernel without semaphore functionality, (1) creating a queue for shared resources using a kernel-supplied queue creation function accessible to threads executing on the HCT; (2) indicating an availability of the shared resource by storing an event object on the queue using a kernel-supplied object delivery function accessible to a thread executing on the HCT; (3) executing a kernel-supplied object retrieval function for retrieving the event object from the queue from a first thread, wherein the event object is not on the queue; A first thread is suspended by the kernel; (4) executing a kernel-supply object search function that attempts to retrieve the event object from the queue, from a second thread, stopping the second thread if the event object is not retrieved from the queue. Steps; (5) an operation of the object retrieval function disclosed in step (4) after executing a kernel-supplied object release function of returning the event object back to the queue from a third thread; Steps to resume A semaphore function implementation method comprising a. The method of claim 17, And said step (2) comprises storing a plurality of event objects corresponding to each of a plurality of shared resources on said queue.