Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1995-07-26
2004-05-04
Toplu, Lucien U. (Department: 2755)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000, C709S241000
Reexamination Certificate
active
06732138
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates in general to a method and system for data processing and in particular to an improved method and system for accessing system resources within a multitasking data processing system. Still more particularly, the present invention relates to a method and system for accessing system resources within a multitasking data processing system which implements a multithreaded operating system kernel that supports kernel-only threads within user processes.
2. Description of the Related Art
A number of currently available multitasking operating systems such as AIX (Advanced Interactive Executive) enable multiple application programs to concurrently execute and share system resources within a data processing system. Typically, each application program comprises one or more processes, which are entities allocated system resources by the operating system. The operating system itself includes a lowest layer, called a kernel, which interacts with the data processing system's hardware. Like application programs, the kernel comprises multiple processes, which synchronize various system activities, implement multiprocessing capabilities, dispatch process threads, and provide interrupt handling services to device drivers.
Referring now to
FIG. 4
, there is depicted a conceptual diagram of conventional user and kernel processes within a data processing system. As illustrated, a multitasking data processing system concurrently executes multiple user processes
100
, which are each allocated a distinct user address space as well as ownership of other system resources. Each user process
100
comprises one or more user threads
102
. As will be understood by those skilled in the art, user threads
102
are abstract entities within the portable programming model for which an application designer writes code. Each user thread
102
is mapped to one or more kernel threads
104
in an implementation dependent manner.
Kernel threads
104
are schedulable entities that execute program steps and consume system resources owned by the processes which include kernel threads
104
. Each kernel thread
104
has an associated machine state that consists of the processor register contents, program counter, and other privileged information required to execute kernel thread
104
. Multiple kernel threads
104
can execute simultaneously when multiple CPUs are available. When only a single CPU is available, the operating system allocates CPU time slices to each of kernel threads
104
to create an appearance of concurrent execution.
As described above, the operating system kernel includes multiple concurrent kernel processes
106
. Each kernel process
106
represents a registered segment of code available to support a function of the data-processing system. For example, the operating system of a data processing system typically includes a number device drivers utilized to manage devices coupled to the system bus of the data processing system. Each of kernel processes
106
can be utilized by the operating system to provide services, such as interrupt handling, for these device driver routines. As illustrated, kernel threads
107
, which form kernel processes
106
, execute only within a kernel mode environment. Both kernel process kernel threads
107
and user process kernel threads
104
can reference the globally accessible kernel data structures utilized to control operation of the data processing system and to define system resources allocated to each user process
100
.
While a kernel thread
104
running under a user process
100
is executing application instructions, kernel thread
104
operates within a user mode environment. However, during its stream of execution, a kernel thread
104
may require access to system resources, for example, to perform a disk read or other asynchronous I/O, which are accessible only from the kernel mode environment. To access these system resources, kernel thread
104
first describes the desired I/O operation utilizing a control block data structure within the user address space assigned to user process
100
. In addition, kernel thread
104
specifies whether a notification signal should be issued to kernel thread
104
when the requested data is available. Kernel thread
104
then makes a system call to change domains from the user mode to the kernel mode environment.
Within the kernel mode environment, kernel thread
104
makes a kernel service call to the kernel address space, as illustrated by arrow
108
, requesting that a kernel thread
107
running under a kernel process
106
perform the access to the system resources. The kernel service call entails allocating a control block within the kernel address space, filling out the control block, and inserting the control block into the kernel process request queue. Following kernel service call
108
, kernel thread
104
returns to the user mode environment and continues execution.
Upon receipt of kernel service call
108
, a kernel thread
107
which supports the requested functionality wakes from sleep, that is, a state of suspended execution, and moves the control block from the kernel process request queue to a pending I/O queue. In the case of an asynchronous read, kernel thread
107
then interfaces with a device driver routine to initiate an access to the disk hardware, as illustrated by arrow
112
. Data read from the disk is stored within the global kernel address space. While waiting for the I/O request to complete, kernel thread
107
sleeps unless other I/O requests serviced by kernel thread
107
are received. Upon completion of the requested asynchronous read, kernel thread
107
is awakened by an interrupt from the disk interrupt handler, indicating that an asynchronous read has completed.
After kernel thread
107
wakes, kernel thread
107
determines which I/O request has been completed. Kernel thread
107
then copies the data from the kernel address space to the address space of user process
100
. Because kernel thread
107
runs under a different process from the calling kernel thread
104
, kernel thread
107
must obtain locks on a portion of the address space of user process
100
to ensure that the address space is not reallocated before the data transfer is complete. Once the data is copied into the user address space of user process
100
, kernel thread
107
updates a status indicator within the control block of user process
100
to indicate that the requested data is available. In addition, if requested by user process
100
, kernel process
106
transmits a signal to user process
100
to indicate that the requested data is available. Kernel process
106
then returns to sleep. After receiving notification of the availability of the requested data from kernel process
106
or by checking the status indicator within its control block, kernel thread
104
can then utilize the accessed data in its stream of execution.
Although the programming model illustrated conceptually in
FIG. 4
provides enhanced performance over prior programming models which did not support multithreaded processes, the programming model depicted in
FIG. 4
does not promote accountability for the use of system services by user processes
100
. In other words, each user process
100
can consume system resources available through kernel processes
106
without regard to the priority of user process
100
since kernel processes
106
provide generic response to kernel service calls issued by kernel threads
104
. Because of the generic support provided by kernel processes
106
, kernel service calls issued by a high priority kernel thread
104
running under a user process
100
can be delayed in favor of a call issued by a lower priority kernel thread
104
. In addition, when kernel threads running under multiple user processes
100
request a particular system resource accessible only through a single kernel process
106
, the programming model illustrated in
FIG. 4
requires that all of the kernel service calls be placed within a single
Browning Luke Matthew
Peek Jeffrey Scot
Bracewell & Patterson L.L.P.
International Business Machines - Corporation
Roberts Diana L.
Toplu Lucien U.
LandOfFree
Method and system for accessing system resources of a data... 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 system for accessing system resources of a data..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for accessing system resources of a data... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3224728