Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-04-27
2002-09-24
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000
Reexamination Certificate
active
06457064
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to the field of computer software and client/server applications. In particular, it relates to directing data from clients to appropriate processes and threads in a multi-threaded operating system.
2. Discussion of Related Art
As network and distributed computing environments expand, the processing demands on operating systems running and supporting these environments increase. As networks grow, the number of users and the amount of data expand while expectations regarding response time and general operating system features increase with time. In some cases, while resources available in an operating system, especially those running in a distributed computing environment, may have been adequate for the number of users or volume of data initially contemplated for the network, these resources become increasingly valuable as the demands on the network grow. The volume of individual user requests grows while the operating system's pool of resources remains constant.
Two particular kinds of resources used by an operating system are generic processes and thread-execution enablers referred to in some operating systems as light weight processes. One type of generic process has its own pool of resources, such as memory, file descriptors, and stack routines. Existing within this type of process is, in most cases, a variety of threads, a thread being a piece of executable computer code designated to accomplish a specific and generally narrow task.
The types of threads contained in a process vary according to the function and overall requirements of the process and operating system. Behind each process and thread is a light weight process which enables the process or thread to execute by making system calls and performing input and output operations on behalf of the process or thread. For example, a light weight process allows a piece of code to make calls to the operating system. Thus, a thread or process effectively can not operate without being assigned a light weight process by the operating system. Typically, a light weight process is assigned to a thread when the thread makes a system call. However, an operating system normally has a limited number of light weight processes it can assign and this pool can be depleted if the number of processes and threads rapidly increases.
In some cases, a process, or threads within a process, may be waiting on an external event to occur or for input from an external source. For the process or thread to be “listening” for some type of external signal or data, it requires that it have a light weight process behind it. If the number of threads waiting for input or the number of processes running keeps growing, the more light weight processes the operating system will need to assign. When all the light weight processes have been assigned and a process P
1
is ready to execute (and, thus, needs a light weight process), some operating systems perform context switching with another process, for example, P
2
. Context switching is a comparatively resource-intensive operation where the operating system to accommodate the needs of P
1
, saves the context of P
2
, restores the context of P
1
and assigns to it the now available light weight process from P
2
. The system then allows P
1
to run and, when it is complete or remains idle, restores the context of P
2
and assigns the light weight process. This type of context switching (i.e. saving and restoring processes' contexts) for entire processes normally requires significant processing time and system resources and, thus, is undesirable. The concept of having threads within a process stemmed from the desire to reduce process context switching.
It is also undesirable to have each thread, especially in high-volume multi-threaded operating systems, assigned its own exclusive light weight process. This situation is particularly inefficient and wasteful given that, in many situations, threads are idle or in some type of input wait state most of the time, where they are not actively processing data or executing. In a high-volume network with thousands of users, the number of light weight processes can begin to run low. This problem is also true in smaller networks where the number of light weight processes available in the operating system may have been initially set to be relatively small. Even though starting and stopping a light weight process does not require significant overhead, it is very desirable for the operating system to always have them available when needed. Regardless of the size of the computing environment, threads can easily proliferate and consume valuable system resources, such as light weight processes.
Therefore, it would be desirable to have a mechanism that would decrease the number of light weight processes assigned to threads, particularly in the context where the threads require the light weight process solely to detect an external signal directed to that thread. It would be desirable for the operating system to assign a light weight process to a thread that requires the light weight process for execution only, thereby making more efficient use of the system's light weight processes and fostering overall savings in system resources.
SUMMARY OF THE INVENTION
To achieve the foregoing, and in accordance with the purpose of the present invention, methods, apparatus, and computer readable medium for handling an input event directed to a thread within a process operating in a multi-threaded system are disclosed. In one aspect of the present invention, a method is provided in which a process is alerted that an input event effecting one of its active connection threads has been received. A special thread referred to as an input polling thread in the process is enabled and is used, in conjunction with other thread-specific data, to determine which of the threads in the process has an event directed to it. That thread is then triggered to handle the input event.
In one embodiment an execution enabler, such as a light weight process, is assigned to the input polling thread and then run thereby enabling the input polling thread. In yet another embodiment, a list of threads maintained by a process is checked wherein each thread can be identified by a file descriptor and has an associated thread identifier, a thread wait variable, and an error return code. The state of a thread wait variable is changed when an input event directed to a thread associated with the thread wait variable is received.
In another aspect of the invention, a method of invoking a thread in a process when an input event is received and using a reduced number of light weight processes is disclosed. An input event directed at an active connection thread is received and a polling thread is used to determine which active connection thread the input event is directed to. A single light weight process is used by the appropriate active connection thread to handle the input event only such that the light weight process is assigned to the thread only after it is determined that the input event is directed to that thread. In one embodiment a conditional wait thread is run to monitor changes made to the active connection threads receiving an input event to ensure execution of those selected active connection threads.
In another aspect of the invention, a computer system configured to receive input from users where the input is directed to a specific thread contained in a process is disclosed. An input polling thread detects input events directed to active connection threads in the process and routes the event to the selected thread. Only the input polling thread requires a light weight process for detecting the input event thereby reducing the need for light weight processes used by the active connection threads, which would previously be needed for detecting input events. An input wait table associated with the process is structured for monitoring and storing information on the active connection threads where the information ind
Huff Daryl A.
Yeager William J.
Beyer Weaver & Thomas LLP
Courtenay III St. John
Nguyen Van H.
Sun Microsystems Inc.
LandOfFree
Method and apparatus for detecting input directed to a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for detecting input directed to a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for detecting input directed to a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2878063