Patent Application
20080040560
While the invention is claimed in the concluding portions hereof, preferred embodiments are provided in the accompanying detailed description which may be best understood in conjunction with the accompanying diagrams where like parts in each of the several diagrams are labeled with like numbers, and where:
The present invention provides a runtime technique to reduce the cost of a read-only lock on computer architectures that have support for atomic memory update that consists of separate load-and-reserve (or load-and-link) and store-conditional machine instructions such as Alpha, MIPS and PowerPC.
The invention can take the form of an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. As used herein, the term “data processing system” is intended to have a broad meaning, and may include personal computers, laptop computers, palmtop computers, handheld computers, network computers, servers, mainframes, workstations, cellular telephones and similar wireless devices, personal digital assistants and other electronic devices on which computer software may be installed.
Input/output or 170 devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.
Network adapters may also be coupled to the system to enable the data, processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems and Ethernet cards are just a few of the currently available types of network adapters.
The processor 3 can be any processor that is typically known in the art with the capacity to run the program and is operatively coupled to the memory 4. The memory 4 is operative to store data and can be any storage device that is known in the art, such as a local hard-disk, etc. The input device 5 can be any suitable device suitable for inputting data into the data processing system 1, such as a keyboard, mouse or data port such as a network connection and is operatively coupled to the processor 3 and operative to allow the processor 3 to receive information from the Input device 5. The program module 8 is stored in the memory 4 and is operative to provide instructions to the processor 3 and the processor 3 is responsive to the instructions from the program module 8.
In an embodiment of the invention, a lava application 30 calls for a lock on a piece of shared data. Conventional computer system 1 has an operating system 20 on top of which runs a Java virtual machine 25. The Java virtual machine 25 operates as a virtual operating system and the Java application 30 is supported running on the Java virtual machine 25. Java bytecode is passed to the Java virtual machine 25 and the Java virtual machine 25 generates a corresponding implementation of the lock in a lower level code.
Although other internal components of the data processing system 1 are not illustrated, it will be understood by those of ordinary skill in the art that only the components of the data processing system 1 necessary for an understanding of the present invention are illustrated and that many more components and interconnections between them are well known and can be used.
In the method a first register is used to hold the value of a lock word that indicates whether a lock has been acquired for the piece of shared data, a second register is used to store the address of the piece of shared data that is accessed by the method and a third register is used to store the piece of shared data when it is accessed by the method. It is to be understood for the purposes of the examples that the terms “first”, “second” and “third” are used in reference to the registers merely to distinguish between different registers and do not necessarily refer to the first, second and third available registers. A person skilled in the art will appreciate that various available registers in accordance with the particular computer architecture that is being used could be used to implement the following method.
The steps of the method comprise: loading a lock word and reserving the memory location the lock word was loaded from 105; testing to see if the lock is free 110; calling outofline_aquire if the lock is not free 115; conditionally storing a value to the lock word to acquire the lock 120 if the lock is free; a synchronization instruction 125; loading a piece of shared data 130; loading a zero value 135; checking the lock word 140; comparing the lock word against a thread id 145; another synchronization instruction 150; calling outofline_release 155; and freeing the lock 160 before ending.
Steps 105, 110, 115 and 120 acquire a lock on a piece of shared data. The method begins at step 110 with the lock being loaded into a first register and a reserve placed on the location in memory that the lock word was loaded from. The load and reserve at step 105 works in conjunction with a store conditional instruction at step 120. The reserve is set in the processor and if the address the lock was stored in is updated by another thread the processor will detect this update of the data at the address and clear the reservation. At step 120 with the store conditional command, if the reserve is not still present, the store instruction fails. The load and reserve at step 105 is part of the atomic memory update sequence.
After the lock word is loaded into a first register at step 105, step 110 tests the lock word to determine whether the lock is free or whether the lock has been acquired by another thread. If the lock implementation uses a zero (0) value of the lock word to indicate a free flat lock, such as in a Tasuki lock implementation (although other types of lock implementation could also be used), a value of zero (0) for the lock word indicates that the lock is free and a non-zero value of the lock word indicates that the lock has been acquired by another thread. If the lock is free the method can continue on and acquire the lock and access the piece of shared data. However, should the lock not be tree (i.e. the lock word contains a non-zero value), a call to outofline_acquire is invoked 115.
The outofline_acquire 115 handles the case where the shared data is locked. It can handle a recursive lock enter if the thread has already acquired the lock, dealing with contention if another thread currently holds the lock or handling an inflated lock. The call at step 115 calls out of line code that handles the infrequent cases where the lock is not free. This out of line code checks for a recursive acquire of a flat lock and in that case all that is necessary is to increment the count part of the flat lock (the one special case is an overflow of the count field, forcing inflation of the lock).
If the lock is identified as free at step 110, the thread attempts to acquire the lock by writing a value to the lock word in memory at step 120. For a Tasuki lock implementation a lock is acquired by writing a non-zero value into the lock, word, where the value is some type of thread identifier indicating the owning thread and part of the lock word (separate from the thread identifier) is used as a counter to implement recursive locking (with a count of zero (0) indicating that the lock is locked but not recursively locked). A conditional store instruction is used at step 120 and a new value for the lock word will only be stored in the location in the memory storing the lock word if the reserve from step 105 is still present. At step 110, if the reserve is not present, indicating that the lock word in memory has been updated since the lock word was loaded into a first register at step 105 and therefore likely not free, the store at step 120 will fail and the method loops back and tries to acquire the lock again starting with step 105. If at step 120, the reserve is still present, the lock word stored in memory has not been updated and the store will be successful.
If the store at step 120 is successful, the lock word stored in memory indicates to the other threads that the shared data has been locked by this thread and the method proceeds to step 125 Step 125 is an instruction to synchronize the execution of instructions. For a PowerPC computer architecture the instruction used is an isync instruction, however, other computer architectures might use different but substantially corresponding instructions to achieve a similar result. The synchronization at step 125 is a memory barrier which causes all the instructions indicated previous to the synchronization step 125 to be performed. Because a processor can perform instructions out of order, without this synchronization instruction at step 125, later steps might be performed before earlier steps. For example, without the synchronization at step 125 a processor implementing the method might perform step 130 before step 110. Step 125 prevents execution of the steps following step 125 before ail the previous steps have been completed. In this implementation of the lock, step 125 is required to ensure that any accesses to the shared data are not yet started. This synchronization step is a major cause of overhead in the implementation of tins lock.
Step 130 loads the piece of shared data into a second register and is the portion of the method where the piece of shared data is accessed by the thread. This is the step where the shared data is actually read.
Finally, steps 135, 140, 145, 150, 155 and 160 comprise the portion of the method where the lock is released.
Step 135 loads a zero (0) value into a third register.
Step 140 loads the lock word into the first register and step 145 compares the value of the lock word against the thread identifier of the thread to determine whether the lock has been acquired by the present thread.
Step 150 is another synchronization step. Step 150 is required to guarantee previous load or store operations to the piece of shared data are completed before the method continues. Using a PowerPC computer architecture, the synchronization instruction used is 1 wsync (however, corresponding instructions may be used for different computer architectures) which controls the ordering of storage accesses to system memory only and while it does not require as much processor overhead as other synchronization instructions, such as isync, it still increases processor overhead.
Step 155 calls an outofline_release. This out of line code handles infrequent cases, returning to the label outofline_release_return. The out of line code first checks for a recursive release of a flat lock, and in that case all that is necessary is to decrement the count part of the flat lock.
Step 160 frees the lock, allowing other threads to acquire the lock and gain access to the piece of shared data. The lock is freed by writing a value to the lock word in memory indicating that the lock is free, if the lock is implemented as a Tasuki lock implementation, a zero value (0) is written into the location of the memory where the lock word is stored.
After the lock is freed at step 160 the method ends.
An example of assembler code of a sample PowerPC instruction sequence for the method illustrated in
The conventional lock implementation illustrated by the flowchart in
The lock exit operation again requires some synchronization. Synchronization must be used to guarantee that all read or write operations on the piece of shared data have been completed before the lock is treed by writing a new value to the lock word.
Dynamically, a large majority of locking operations are to acquire a tree flat lock or to release a flat lock with a zero count. A much less frequent locking operation is to recursively acquire or release a flat lock. Quite infrequently there is an attempt to acquire a lock owned by another thread (a contended case), or to have an inflated lock. If the piece of shared data is only accessed through read operations, the implementation of a flat lock can be improved by simplifying the instruction sequence and eliminating some memory barrier operations which are typically the most expensive parts of the conventional implementation illustrated in
In addition, because the lock is a read-only lock, and there is no modification of the piece of shared data, there is no need of some costly synchronization instructions that would be used to actually acquire and then later release the lock and thereby prevent the access to the shared data by other threads. Instead, a load word and reserve index instruction and a corresponding conditional store instruction are used to ensure that the piece of shared data has not been accessed by another thread while the method is being performed.
By not acquiring the lock, but rather simply checking to ensure the lock is free, some synchronization instructions can be avoided. However, even if synchronizations are used, by simply ensuring a lock is free before accessing one or more pieces of shared data rather than acquiring the lock before accessing the one or more pieces of shared data, a store instruction to save a value into the lock word stored in memory can be avoided. Because this avoidance of a store instruction alone provides some benefit in reducing processor overhead, it is contemplated that a lock could be implemented using synchronization instructions yet simply ensuring the lock is free without acquiring the lock in order to reduce the overhead of the lock by avoiding the use of a store instruction.
In the embodiment shown, a first register is used to hold the value of a lock word that indicates whether a lock has been acquired for the piece of shared data, a second register is used to store the address of the piece of shared data that is accessed by the method and a third register is used to hold the contents of the piece of shared data when it is accessed by the method. As noted above, it is to be understood for the purposes of this example that “first”, “second” and “third” are used in reference to the registers merely to distinguish between different registers for the purposes of explaining the method and do not necessarily refer to the first, second and third available registers of a computer architecture. A person skilled in the art will appreciate that various available registers In accordance with the particular computer architecture that is being used could be used to implement the following method.
The method comprises the steps of: loading a lock word from a location in memory and placing a reserve on the location in the memory 205; checking to determine whether the lock is free 210; calling an outofline_read 215 if the lock is not free; creating an artificial dependency 220 if the lock is free; loading a piece of shared data 225; creating another artificial dependency 230; and conditionally storing a value to the lock word in memory 235.
The method starts at step 205 with the lock word being loaded into the first register and a reserve placed on the memory location where the lock word was accessed from.
At Step 210, the lock word is evaluated to determine if the lock is free (i.e. that another thread has not locked the piece of shared data by writing to the location in the memory where the lock word is stored). If the lock word uses a zero (0) value to indicate that the lock is tree, at step 210 the value of the lock word is checked to see if it is zero (0).
If the lock is not free, step 215 calls an outofline_read method. If the lock is already held by this thread, the out of line code need only perform the load and does not need to modify the lock.
This outofline_read method also deals with the case where the lock is in contention or inflated by calling a monitor enter helper, doing the load and then calling a monitor exit helper.
An example of assembler code of a sample PowerPC instruction sequence for the outofline_read method at step 215 is set out in the Example below.
However, if at step 210 the lock is found to be free, the piece of shared data can be accessed and the method moves on to step 220.
Rather than using a synchronization instruction at this point to enforce an ordering of the method steps by creating a memory barrier at this point to ensure that the method checks to see if the lock is free before accessing the piece of shared data, additional operation steps are used to create artificial dependencies between the steps of the present method to take advantage of ordering guarantees of a processor executing the method. By creating these artificial dependencies the processor will implement the steps of the method in order.
Step 220 is an additional instruction that creates an artificial dependency between subsequent step 225, where the piece of shared data is accessed, and preceding steps 205 and 210, where the value of the lock field was loaded into the first register and this value evaluated to determine if the lock was free. Step 220 is not needed to alter any data or modify any values in the method, but by creating an artificial dependency at step 220, the processor, using the rules of dependency between the first and second registers, causes steps 205 and 210, which use the first register, to be performed before step 220, which involves the second register and third register. Without creating these artificial dependencies at step 220 the processor would not see any connection between the use of the first register in steps 205 and 210 and the second register in step 225 because there is no apparent dependency between the first register and second register. Therefore the processor might perform the step 225 and access the piece of shared data before steps 205 or 210, with the result that the piece of shared data might be accessed by the thread before it is determined that the lock is free. By including this intermediate step where an artificial dependency is created between the first register and the second register, even though this step is not necessary to alter the values stored In the first register and second register, the processor executing the instructions will perform the instructions in a required order so that step 225 is subsequent to steps 205 and 210.
Although a number of different operations can be performed at step 220 to create an artificial dependency between steps 220 and 205, in one embodiment, if a zero (0) value of the lock word is used to indicate that the lock is free, a logical OR operation can be used to create the artificial dependency between steps 205, 210 and 225. By logically ORing the value stored in the first register (which in that case would be zero) with the value stored in the second register (which would indicate the location of the piece of shared data) and storing the result back into the second register, the value stored in the second register is unaltered.
At step 225 the piece of shared data is accessed. The piece of shared data is loaded into the third register from the address where it is located. Because the second register was artificially depended from the first register at step 220, the processor uses its dependency guarantee rules to ensure that step 225 is performed after steps 205 and 210, thereby preventing the piece of shared data being accessed by the method before it is determined whether or not the lock is free.
Alternatively, in some situations, rather than incorporating step 220 so that step 225 has an artificial dependency on steps 205 and 210, it may be possible for step 225 to incorporate the first register in its implementation so that step 225 has a created artificial dependency on steps 205 and 210, without requiring the additional instruction at step 220 to create this dependency. For example, if the value being loaded into the first register is a zero value, step 225 could be altered so that the first register holding this zero value is used in the accessing of the piece of shared data. Rather than using a zero (0) value to access the piece of shared data, the first register could be used in place of the zero (0) value to create an artificial dependency (i.e. rather than implementing step 225 in PowerPC as “1wz r31, 0(r8)”, step 225 could be altered as follows: “1wzx r31, r8. r5”, where r31 holds the value of the shared value, r8 indicates the location in memory of the piece of shared data, and r5 holds the lock word which in this case would be a zero value). In this manner, it is possible in some situations for step 225 to be implemented with an artificial dependency created on steps 205 and 210 without requiring the additional instruction at step 220.
Step 230 is another additional instruction that creates an artificial dependency between steps in the method. Step 230 creates a dependency between subsequent step 235 and preceding step 225. The result of the load at step 225 is dependent on the first register so that the conditional store of step 235 is not performed by the processor until after the piece of shared data is accessed at step 225.
In one embodiment a logical exclusive OR instruction is used to exclusively OR the value of the third register together with itself and save the result in first register where the value of the lock is stored. Because it was determined at the preceding step 210 that the value of the lock field is zero (0), the results of the same value exclusively OR'd with itself will be zero (0) which is already the value of the lock word stored in the first register so all of the values stored in the registers are unaltered by step 230.
At step 235 a conditional store is used to store a value back into the lock word stored in the memory. If a value of zero (0) in the lock word is used to indicate the lock is free, a zero (0) value is written back into the lock word stored in the memory. Step 235 works in conjunction with step 205. At step 235, before a value is stored back into the lock word in memory, the reserve placed on the memory at step 205 is checked to see if the reserve is still set. If the reserve is still present, this indicates that the lock word in the memory has not been accessed by another thread and the store will be completed and the method ends. However, if the reserve has been removed (i.e. another thread has accessed the lock word in the memory while the present method was being performed) the store at step 235 fails and the method loops back to step 205 and begins again. By using the corresponding instructions of a load and reserve at step 205 and a conditional store instruction at step 235 it can be guaranteed that the piece of shared data has not been altered by another thread while the present thread was accessing the shared data.
An example of assembler code of a sample PowerPC instruction sequence for the method illustrated in
Some programming languages, such as Java, require a monitor exit to ensure that all stores to shared data before the monitor enter be visible to other threads before the lock is freed. A StoreExit barrier is required even for a read-only lock sequence. In circumstances where a StoreExit barrier is required, the method illustrated by the flowchart in
While the flowchart in
Steps 205, 210, 215, 220, 225 and 230 are the same steps as the steps of the method illustrated in
Step 250 has been inserted and is a conditional store command that stores a value to a location in memory that contains the lock word so that the thread acquires the lock. The conditional store command at step 250 works in conjunction with the load and reserve command at step 205 to ensure that another thread did not acquire the lock before the present thread has acquired the lock by writing to the location in memory where the lock word is stored. If at step 250 the reserve has been removed., the lock word has been updated and the store will fail causing the method to loop back to step 205 to attempt to acquire the lock again.
Because the present method acquires the lock at step 250 with a conditional store, step 255 also differs from step 235 of the method illustrated by the flowchart in
Again, artificial dependencies between the steps of the method are created with additional instructions at steps 220 and 230 to ensure a processor performs the instructions in the method in a required order. Step 220 creates an artificial dependency between previous steps 205, 210 and 250 and the later subsequent step 225, causing a processor to perform these steps in a required order. Step 230 creates an artificial dependency between previous step 225, where the piece of shared data is accessed and step 255, where the lock is freed, causing a processor to perform the steps in this order and preventing the lock being freed before the piece of shared data has been accessed by the method.
The method illustrated in
By ensuring that artificial dependencies are created between the load operations, where the pieces of shared data are accessed, and the load and reserve command at step 205, where the lock word is obtained, and another set of artificial dependencies are created between the load operations, where the pieces of shared data are accessed, and the conditional store instruction at step 235, a required order of execution of the steps in the method is ensured and any practical number of pieces of shared data can be protected by the lock using the illustrated method. A computer program may access one or more of the pieces of shared data protected by a particular lock word when using a read-only lock according to an aspect of the present invention. What is important is that none of the pieces of data protected by a particular lock is accessed unless the lock is free.
In one embodiment of the present invention the improved read-only flat lock implementations are accomplished in a program using a compiler optimization technique (e.g. a lava Just-in-Time (JIT) compiler). The methods illustrated in
The method begins by analyzing a lock portion of a program code at step 405. The method is executed by a compiler at compile time with the program code being a particular target program code, such as source code of high-level code that the compiler is converting into a low-level code implementation as the output code with the output code corresponding to the source code. Alternatively, the compiler could be compiling a Java application as it executes and the target program code could be the Java bytecode from the Java application.
Step 410 identifies whether the lock portion of the program code is a read-only lock. For the lock portion of the program code to be a read-only lock a number of criteria must be met, such as: the synchronized region of code does not contain any writes to global data structures or global variables; the synchronized region of code does not contain other locks nested inside; the synchronized region of code does not contain exception points; and finally the synchronized region of code must be restricted to be read-only on all control flow paths in the code.
In response to determining at step 410 that the lock portion of the program code is not a read-only lock, a conventional lock implementation is generated at step 430 and used to implement the called for lock sequence. This conventional lock implementation could be similar to the implementation illustrated in
In response to determining at step 410 that the lock portion of the program code is a read-only lock, if the program language has specific requirements for the use of monitor exit, such as the Java language that requires a monitor exit to ensure that all stores to shared data before the monitor enter be visible to other threads before the lock is freed, the method analyzes the program code leading up to the lock portion at step 415 and if it can be determined that there are no writes to shared data since the last StoreExit barrier (such as a monitor exit or volatile store), then the compiler can mark this read-only lock sequence as not requiring a StoreExit barrier.
If a StoreExit barrier is not required, an improved low-level code lock sequence, such as an improved low-level lock implementation as shown in
However, if it is determined that a StoreExit is needed or that it cannot be determined whether or not a StoreExit is needed, an improved low-level code lock implementation, such as the implementation shown in
Once the code has been generated either at step 430, 420 or 425, the method ends.
The foregoing is considered as illustrative only of the principles of the invention. Further, since numerous changes and modifications will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation shown and described, and accordingly, ail such suitable changes or modifications in structure or operation which may be resorted to are intended to fall within the scope of the claimed invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2539908 | Mar 2006 | CA | national |
