The present invention relates to digital data processing, and in particular to methods and apparatus for sharing resources among multiple software processes.
In the latter half of the twentieth century, there began a phenomenon known as the information revolution. While the information revolution is a historical development broader in scope than any one event or machine, no single device has come to represent the information revolution more than the digital electronic computer. The development of computer systems has surely been a revolution. Each year, computer systems grow faster, store more data, and provide more applications to their users.
A modern computer system typically comprises one or more central processing units (CPU) and supporting hardware necessary to store, retrieve and transfer information, such as communication buses and memory. It also includes hardware necessary to communicate with the outside world, such as input/output controllers or storage controllers, and devices attached thereto such as keyboards, monitors, tape drives, disk drives, communication lines coupled to a network, etc. The CPU or CPUs are the heart of the system. They execute the instructions which form a computer program and directs the operation of the other system components.
From the standpoint of the computer's hardware, most systems operate in fundamentally the same manner. Processors are capable of performing a limited set of very simple operations, such as arithmetic, logical comparisons, and movement of data from one location to another. But each operation is performed very quickly. Sophisticated software at multiple levels directs a computer to perform massive numbers of these simple operations, enabling the computer to perform complex tasks. What is perceived by the user as a new or improved capability of a computer system is made possible by performing essentially the same set of very simple operations, but using software with enhanced function, along with faster hardware.
Almost all modern general purpose computer systems support some form of multi-tasking, in which multiple processes are simultaneously active, and computer system resources, particularly processor resources, are allocated among the different processes. Multi-tasking supports a more efficient use of the various hardware resources by enabling a resource which is temporarily not needed by one process to be used by a different process. Multi-tasking thus increases overall throughput, i.e., overall work performed in a given time.
Multi-tasking inevitably causes contention among the active processes for certain resources. As the number of active processes increases to more fully utilize key resources, this contention becomes more serious. Eventually, the number of active processes can become so large that contention for resources begins to adversely affect performance. In other words, at some point the addition of more active processes will degrade throughput, because the benefit of increased resource utilization is outweighed by the increased contention these additional processes entail.
Resources which are shared by active processes can be either hardware resources (processors, memory space, etc.) or software resources (shared data structures, shared code paths). There are certain resources which, by their nature, are capable of being utilized by multiple processes simultaneously, but which are heavily optimized to operate more efficiently when utilized by a single process at a time. In particular, executable code is generally available for use by multiple processes simultaneously, but there are certain code paths which result in much faster execution if only one process or thread is executing in the code path at any given time.
In such a situation, it would be possible to regulate access to the resource by use of a lock. A lock is a software mechanism by which a single process is granted the exclusive temporary use of a resource, and when finished relinquishes the lock so that the resource may be used by other processes. A lock therefore guarantees that only one process can utilize the resource at a time. However, the granting and relinquishing of locks itself involves considerable overhead. For this reason, locks are typically used only to regulate access to resources which can not be simultaneously accessed, e.g., where simultaneous access could compromise data integrity.
It would be desirable to reduce contention of multiple processes for shared resources, and particularly for software resources, without the high overhead associated with conventional lock mechanisms.
A soft lock mechanism for a shared computer system resource controls access by multiple processes to a shared resource to make simultaneous access an unlikely event, while not necessarily making simultaneous access impossible. Preferably, the soft lock limits the grant of access within a time interval after a previous grant, the time interval calculated to make simultaneous access unlikely. Expiration of the time interval allows a soft lock to be granted to another process, without requiring explicit release of the soft lock by a previous process.
In the preferred embodiment, a soft lock contains a next_free_time field, specifying the earliest time at which the soft lock will be available, and a lock_duration, specifying a time interval assumed to be sufficiently long for most processes to finish using the resource. The lock is obtained for a requesting process by comparing the current time to next_free_time. If the current time is later than next free time, then the lock is granted immediately, and next_free_time is updated to the current time plus lock_duration. If the current time is before next_free_time, then next_free_time is updated to next_free_time plus lock_duration, and the requesting process waits until the old next_free_time to obtain the lock. No action is required to release the lock.
By providing a relatively low overhead “soft lock” mechanism, it is feasible to provide locks for certain resources to reduce contention which might adversely affect performance. Overhead is reduced because no action is required to release a soft lock once a process has finished using the shared resource. The low overhead soft lock does not guarantee the elimination of all contention, since it is possible that a first process given the lock will not be finished with the resource before a second process starts. However, it makes contention a much less frequent event. Such a “soft lock” is therefore a useful tool for controlling access to certain resources, where simultaneous access would not compromise system integrity, but would have a significant adverse effect on performance.
The details of the present invention, both as to its structure and operation, can best be understood in reference to the accompanying drawings, in which like reference numerals refer to like parts, and in which:
The general subject of the present application is the sharing of resources among multiple active processes, tasks, jobs, threads or similar constructs in a multi-tasking system. In general, a task or job is an executing instance of a computer program or function on behalf a particular user, having its own state. A task or job may contain a single thread of execution, or may spawn multiple threads. Different computer system architectures use different terms to describe similar concepts, and there are sometimes subtle distinctions between the usage of these terms. Access rights to a resource may be granted to tasks or jobs, or may be granted to threads, depending on the system architecture, type of resource, and other factors. As used in the present application, a “process” includes any or all of the above or similar constructs to which access to a shared resource may be granted or from which it may be withheld.
Referring to the Drawing, wherein like numbers denote like parts throughout the several views,
System 100 contains one or more general-purpose programmable central processing units (CPUs) 101A-101D, herein generically referred to as feature 101. In the preferred embodiment, system 100 contains multiple processors typical of a relatively large system; however, system 100 could alternatively be a single CPU system. Each processor 101 executes instruction stored in memory 102. Instructions and other data are loaded into cache memory 106 from main memory 102 for processing. Main memory 102 is a random-access semiconductor memory for storing data, including programs. Although main memory 102 and cache 106 are represented conceptually in
Buses 103-105 provide communication paths among the various system components. Memory bus 103 provides a data communication path for transferring data among CPUs 101 and caches 106, main memory 102 and I/O bus interface unit 105. I/O bus interface 105 is further coupled to system I/O bus 104 for transferring data to and from various I/O units. I/O bus interface 105 communicates with multiple I/O interface units 111-114, which are also known as I/O processors (IOPs) or I/O adapters (IOAs), through system I/O bus 104. System I/O bus may be, e.g., an industry standard PCI bus, or any other appropriate bus technology.
I/O interface units 111-114 support communication with a variety of storage and I/O devices. For example, terminal interface unit 111 supports the attachment of one or more user terminals 121-124. Storage interface unit 112 supports the attachment of one or more direct access storage devices (DASD) 125-127 (which are typically rotating magnetic disk drive storage devices, although they could alternatively be other devices, including arrays of disk drives configured to appear as a single large storage device to a host). I/O and other device interface 113 provides an interface to any of various other input/output devices or devices of other types. Two such devices, printer 128 and fax machine 129, are shown in the exemplary embodiment of
It should be understood that
Although memory bus 103 is shown in
Main memory 102 is shown in
Computer system 100 depicted in
While various system components have been described and shown at a high level, it should be understood that a typical computer system contains many other components not shown, which are not essential to an understanding of the present invention. In the preferred embodiment, computer system 100 is a computer system based on the IBM i/Series™ architecture, it being understood that the present invention could be implemented on other computer systems.
For any of various reasons, it may be undesirable for two active processes to access or use some particular shared resource simultaneously. Operating system 201 may include any of various lock mechanisms 203 to control access to a shared resource, as are known in the art. One such lock mechanism is shown by example in
In the preferred embodiment, operating system 201 further includes at least one soft lock mechanism 204, one such mechanism being shown for illustrative purposes in
Software components of system 100 may further include one or more user application computer programs 205-207, of which three are shown for illustrative purposes in
System 100 maintains separate process state data 209A-I for each of multiple active processes (herein referred to generically as feature 209). Process state data may include, e.g., a process identifier, a user identifier, a call-return stack, access rights, and any other required data which is unique to the process.
Various software entities are represented in
While the software components of
Soft lock state data structure 301 comprises a next_free_time field 303 and a lock_duration field 304. Next_free_time field 303 stores the earliest time at which the soft lock is available to another requesting process. Lock_duration field 304 stores the nominal duration of the soft lock. In operation, next_free_time is incremented each time a soft lock is granted using the lock_duration, as described more fully herein.
Soft lock state data may optionally include any of various additional data, represented as features 305-308. In one variation, soft lock state data may include one or more alternate lock_duration values 305-306 (of which two are represented in
Soft lock state data 301 may include any of various additional data, depicted generally as feature 308. For example, such additional data 308 could include access rights or access control lists to the shared resource and/or to the soft lock itself.
Although the soft lock state data 301 is represented in
The shared resource to which soft lock 204 controls access could be any shared hardware or software resource on system 100 which meets the basic criteria for use of a soft lock, i.e., for which shared access is acceptable (in the sense that it does not compromise security, data integrity, and so forth), but for which shared access is undesirable (for example, because it adversely affects performance). One example of such a shared resource is a low-level operating system function which is dispatched for execution to multiple processors; in such a case, internal processor mechanisms may assure system integrity, but the concurrent execution of multiple instances of such a function may affect performance. Another such example is a segment of code which itself obtains numerous locks (i.e., conventional exclusive locks) for respective shared resources. In such a case, the locks may assure system integrity, but if multiple processes are attempting to invoke the same code segment simultaneously, there will be a lot of contention for the locks and consequent effect on performance.
In accordance with the preferred embodiment of the present invention, when a process wishes to access a shared resource accessed via a soft lock, the soft lock function checks next_free_time field 303. If next_free_time is before the current time, then the soft lock is immediately available and is granted to the requesting process. In this case, next_free_time is incremented to the current time plus the value of lock_duration 304. If next_free_time is after the current time, the requesting process must wait until next_free_time. In this case, next_free_time in incremented by the value of lock_duration 304. It is assumed that no other process will be using the shared resource after next_free_time, and therefore the resource is available exclusively to the requesting process. Similarly, after the interval lock_duration, it is assumed that the requesting process will be done with the shared resource, and it will be available for use exclusively by the next requesting process.
Current time is then compared with next_free_time (step 404). If the current time is later than next_free_time, then the soft lock is available immediately. In this case, the ‘Y’ branch is taken from step 404, and next_free_time is updated to the current time plus the value of lock_duration 304 (step 405). The updated value of next_free_time is the time at which the soft lock will be available to another process. The current time is optionally saved as start_time, indicating when the process obtained access to the shared resource (step 406). The soft lock function then allows the requesting process to access the shared resource (step 410).
If, at step 404, the current time is less than next_free_time, then the requesting process must wait until next_free_time. In this case, the ‘N’ branch is taken from step 404, and the current value of next_free_time is saved as start_time (step 407). Next_free_time is then incremented by the value of lock_duration (step 408). The value of next_free_time as incremented is the time at which the soft lock will be available to another process. The soft lock function then waits until start time is reached, shown as the tight loop at step 409. In the preferred embodiment, step 409 represents idling as a spin lock; however, if relatively long lock durations are involved, it would alternatively be possible to swap out the requesting process. The condition expressed in step 409 could be determined by any appropriate means, e.g., a timer may be set initially to the value of start_time−current time, and upon expiration of the timer the ‘Y’ branch is taken. However determined, upon taking the ‘Y’ branch from step 409, the requesting process is allowed to access the shared resource (step 410).
Since the state variable next_free_time is necessarily shared, the value of this state variable could become corrupted if multiple processes are allowed to execute the procedure represented by steps 402-408 concurrently. The probability or frequency of a corrupted next_free_time value can be reduced by making steps 405 and 408 atomic operations, but can only be eliminated entirely if the entire sequence of steps 402-408 is an atomic sequence which has exclusive access to next_free_time. Any of various mechanisms might be used to assure exclusive access. However, it will be observed that, just as the shared resource controlled by the soft lock can tolerate occasional concurrent access, the soft lock can tolerate occasional corruption of next_free_time. If the value of next_free_time becomes corrupted, i.e., by failing to increment the value, there is some possibility that multiple processes will access the shared resource, which may temporarily affect performance. At some point, a process requests access to the shared resource at a time when there are no pending accesses to the shared resource, causing next_free_time to resynchronize itself by taking the path through steps 404, 405 and 406.
In the preferred embodiment, no action is required to release the soft lock after the requesting process has finished using the shared resource. However, it may be desirable to collect statistical data concerning use of the shared resource, particularly for purposes of adjusting the value of lock_duration 304. A simple form of statistical data collection is represented in
As shown in
Although a particular simple form of statistical data collection is represented in
In one variation of the preferred embodiment, lock_duration is periodically adjusted using the statistical data collected. Preferably, this is performed by a separate asynchronous process which can be triggered by any of various events, such as the elapse of time, a change in system configuration, detection of a performance anomaly, etc.
Lock_duration may be adjusted upward by a fixed increment, or by a fixed percentage, or by a variable amount which depends on the amount by which the ratio of sr_overtimes to sr_acce3sses exceeds T1, or by an adjustment determined in some other manner.
If threshold T1 is not exceeded (the ‘N’ branch from step 504), then the ratio of sr_overtimes to sr accesses is compared to a second threshold T2. If the ratio is less than the second threshold (the ‘Y’ branch from step 506), then too few accesses are exceeding the allotted lock_duration, indicating that the lock_duration may be too long. In this case, lock_duration is adjusted downwards (step 507). As in the case of upward adjustment, lock duration may be adjusted downward by a fixed increment, a fixed percentage, a variable amount which depends on the ratio of sr_overtimes to sr_accesses, or in some other manner.
If there are multiple soft locks in system 100 each having its own respective lock_duration, then a lock duration adjustment process might adjust all lock_duration variables, as shown by optional steps 508 and 509. If more soft locks remain to be adjusted, the ‘Y’ branch is taken from step 508, the next soft lock is selected (step 509), and steps 502-507 are repeated for the next selected soft lock. When all applicable soft locks have been adjusted, the adjustment process becomes inactive and awaits the next trigger event.
Although a particular form of incremental lock_duration adjustment is disclosed herein, it will be understood that lock_duration could be adjusted based on any number of other formulae or techniques.
In general, the routines executed to implement the illustrated embodiments of the invention, whether implemented as part of an operating system or a specific application, program, object, module or sequence of instructions, are referred to herein as “programs” or “computer programs”. The programs typically comprise instructions which, when read and executed by one or more processors in the devices or systems in a computer system consistent with the invention, cause those devices or systems to perform the steps necessary to execute steps or generate elements embodying the various aspects of the present invention. Moreover, while the invention has and hereinafter will be described in the context of fully functioning computer systems, the various embodiments of the invention are capable of being distributed as a program product in a variety of forms, and the invention applies equally regardless of the particular type of signal-bearing media used to actually carry out the distribution. Examples of signal-bearing media include, but are not limited to, volatile and non-volatile memory devices, floppy disks, hard-disk drives, CD-ROM's, DVD's, magnetic tape, and so forth. Furthermore, the invention applies to any form of signal-bearing media regardless of whether data is exchanged from one form of signal-bearing media to another over a transmission network, including a wireless network. Examples of signal-bearing media are illustrated in
Although a specific embodiment of the invention has been disclosed along with certain alternatives, it will be recognized by those skilled in the art that additional variations in form and detail may be made within the scope of the following claims.