System using backward inter-procedural analysis for determining alternative coarser grained lock when finer grained locks exceeding threshold

BACKGROUND

Computer programs and software are ubiquitous and are used not just to direct the functionality of conventional computers but also to control and enhance the functionality of myriad modern products and appliances. For instance, televisions, household appliances, cellular phones, automobiles, medical devices, and so forth, may incorporate computer programs which direct and enhance their functionality.

Increasingly, computers and computer processors are no longer simple single processors executing software in an instruction-by-instruction sequential fashion. The availability of multi-core processors and multiple-processor computing systems is increasing and the demand for concurrent (or parallel) software to take advantage of multi-processor computers and processors is also increasing. Computers and processors are increasingly multiple processors which can concurrently, or in parallel, execute multiple instructions and procedure threads simultaneously. Such concurrent processing (also referred to as “parallelism”) can greatly increase both the speed and processing power of computer systems when correctly exploited.

This increasing availability of multi-core and parallel computer processors is rapidly increasing the availability of parallelism in computing hardware and is greatly increasing the demand on developers to develop and redesign software to exploit the available parallelism. The use of parallelism and concurrency in programming is becoming increasingly more useful, important, and ubiquitous. However, in order to fully exploit the available parallelism, concurrent programs are typically fashioned, implemented, and executed in a way that protects data that might be accessed or modified by multiple concurrent threads of a concurrent process. Synchronization between different threads that may execute simultaneously in a concurrent program is an important component of developing and deploying correct concurrent software.

Software developers have used explicit lock-based synchronization to protect shared data during concurrent processing. However, explicit lock-based synchronization, specified by the software developer, may not be modular, may be error prone, and may not be easily maintained, extended, or modified.

Another solution to the synchronization problem is transactional memory where concurrent threads execute optimistically, assuming a conflict will not occur. In transactional memory, when a conflict does occur, conflicts may be detected after the fact and execution is then rolled back and repeated to alleviate the conflict. In cases of high contention, those cases where multiple conflicting concurrent threads are highly likely to run simultaneously, transactional memory can be very inefficient. Additionally, implementation of transactional memory often requires special hardware support. Transactional memory has also been implemented using software (i.e., software transactional memory). However, software transactional memory has other limitations, too. It is not well suited when programs have externally visible effects (for example if the program shows a message on a screen or writes a file to a disk), these actions are hard to—and sometimes cannot be—rolled back.

Better and more easily written concurrent programs would help to enable the exploitation of multi-core processors and parallel computing systems. Either locks or transactional memory may be employed for protection of shared data which may possibly be utilized by multiple threads during execution of concurrent threads in a concurrent process. Transactional memory will continue to be problematic in systems having high contention. Manually determining and hand coding locks can be both very tedious and time consuming for a software developer and can be prone to error. Further, it may be difficult for a software developer to know or keep track of each piece of data that is shared by multiple threads in a concurrent program or may become shared during subsequent modification or enhancement of the software. Consequently, manually determined locks are not easily extensible when concurrent software is modified or updated and may continue to be a significant source of error.

Using locks that are inferred at execution time may also prove problematic. Locks that are inferred at execution time may cause deadlocks or other bad behavior. Using locks of fine granularity may reduce contention, allowing more exploitation of parallelism, but fine grained locks may also be more difficult to determine and more prone to deadlock. Coarser grained locks might be easier to determine and may be less prone to deadlock but may also be likely to lead to higher contention, causing less exploitation of parallelism and less efficient runtime behavior of concurrent systems.

BRIEF SUMMARY

Embodiments described herein relate to determining and acquiring locks for concurrent programs. For example, embodiments described herein provide for acquiring locks within a concurrent program by identifying atomic sections of a concurrent program and determining one or more locks that are to be acquired when executing the atomic section. In certain embodiments, a compiler will determine the locks for an atomic section during a compile cycle. Embodiments may acquire one or more locks for an atomic section prior to executing an instruction within the atomic section which uses a resource subject to the one or more locks determined for the atomic section.

Embodiments can also prevent deadlock during execution of concurrent programs by acquiring locks determined for an atomic section of a concurrent program early within an atomic section and or/in in an order sorted according to an appropriate total order. In certain embodiments, code expressing the locks to be acquired may be added (e.g., at compile time) to the appropriate location within the code of the program. In certain embodiments, locks may be acquired at runtime by a runtime library.

Additional embodiments described herein relate to determining locks to be acquired for a concurrent program. Locks may be determined by identifying an atomic section of a concurrent program and determining an expression correspondence for the atomic section. One or more locks may be determined for the atomic section from the expression correspondence for the atomic section by using a backward inter-procedural analysis.

Still other embodiments described herein relate to determining fine and coarse grained locks for a concurrent program. An atomic section may be identified for an atomic section of a concurrent program and one or more fine grained locks may be determined for the atomic section. If the fine grained locks for the atomic section exceed a particular bound, the alternative locks may be determined so that all the previously determined fine grained locks are covered by the alternative locks and the alternative locks do not exceed the particular bound.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a computing system in which embodiments described herein may operate;

<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates a method of determining and acquiring locks for an atomic section of a concurrent program;

<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates examples of total orders including a pre-order which may be used as described herein to avoid deadlock within concurrent programs;

<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates the identification of an atomic section of a computer program and the determination of locks for the atomic section using expression correspondence; and

<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates determining locks for a concurrent program by identifying an atomic section, determining fine grained locks, determining if the fine grained locks exceed a particular bound, and determining alternative locks to substitute for some subset of the determined fine grained locks.

DETAILED DESCRIPTION

Embodiments described herein relate to determining and allocating locks for concurrent programs. The embodiments of the present invention may comprise a special purpose or general-purpose computer including various computer hardware, as discussed in greater detail below.

<figref idrefs="DRAWINGS">FIG. 1</figref> shows a schematic diagram of an example computing system <b>100</b> that may be used to implement embodiments of the present invention. The described computing system is only one example of such a suitable computing system and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the invention be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in <figref idrefs="DRAWINGS">FIG. 1</figref>.

Computing systems are now increasingly taking a wide variety of forms. Computing systems may, for example, be handheld devices, appliances, laptop computers, desktop computers, mainframes, distributed computing systems, or even devices that have not conventionally been considered a computing system. In this description and in the claims, the term “computing system” is defined broadly as including any device or system (or combination thereof) that includes at least one processor, and a memory capable of having thereon computer-executable instructions that may be executed by the processor. The memory may take any form and may depend on the nature and form of the computing system. A computing system may be distributed over a network environment and may include multiple constituent computing systems.

Referring to <figref idrefs="DRAWINGS">FIG. 1</figref>, in its most basic configuration, a computing system <b>100</b> typically includes at least one processing unit <b>102</b> and memory <b>104</b>. The memory <b>104</b> may be system memory, which may be volatile, non-volatile, or some combination of the two. An example of volatile memory includes Random Access Memory (RAM). Examples of non-volatile memory include Read Only Memory (ROM), flash memory, or the like. The term “memory” may also be used herein to refer to non-volatile mass storage such as physical storage media. Such storage may be removable or non-removable, and may include (but is not limited to) PCMCIA cards, magnetic and optical disks, magnetic tape, and the like.

As used herein, the term “module” or “component” can refer to software objects or routines that execute on the computing system. The different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system (e.g., as separate threads). While the system and methods described herein may be implemented in software, implementations in hardware, and in combinations of software and hardware are also possible and contemplated.

In the description that follows, embodiments are described with reference to acts that are performed by one or more computing systems. If such acts are implemented in software, one or more processors of the associated computing system that performs the act direct the operation of the computing system in response to having executed computer-executable instructions. An example of such an operation involves the manipulation of data. The computer-executable instructions (and the manipulated data) may be stored in the memory <b>104</b> of the computing system <b>100</b>.

Computing system <b>100</b> may also contain communication channels <b>108</b> that allow the computing system <b>100</b> to communicate with other computing systems over, for example, network <b>110</b>. Communication channels <b>108</b> are examples of communications media. Communications media typically embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information-delivery media. By way of example, and not limitation, communications media include wired media, such as wired networks and direct-wired connections, and wireless media such as acoustic, radio, infrared, and other wireless media. The term computer-readable media as used herein includes both storage media and communications media.

Embodiments consistent with the principles described herein also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise physical computer-readable media such as RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices. Physical computer-readable media, however, does not include signals. The computer-readable media may also be any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media.

Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Concurrent programs are those programs that may have multiple threads which may execute simultaneously on one or more computer processors. Each thread of a concurrent program may access, utilize, and possibly modify any number of variables, fields, and data structures. It is often the case that some or many of the variables, fields, and data structures that are being utilized and modified by a thread of a concurrent program will also be accessed, utilized, and possibly modified by another thread of a concurrent program. Such attempted simultaneously accessed or modified data within concurrent programs may lead to errors or contention within a concurrent program.

Consider, for example, a large bank with multiple branches. If two branches of a bank were attempting to update the account balance in a particular savings account simultaneously, then the resulting balance may be in error. If Branch One and Branch Two both read the original balance at the same time, then both branches would have the same starting balance for their calculations. However, if Branch One calculated and updated the account balance but then Branch Two immediately overwrote the balance information with a different balance that Branch One calculated, then the resulting account balance would be incorrect. The account balance after the two transactions would reflect only the transaction that transpired at Branch Two and the transaction which occurred at Branch One would be lost. Concurrent software suffers much the same problem as that which might be experience by the competing branches of the bank. (Indeed, the two transactions at Branch One and Branch Two may themselves be simultaneous threads within a concurrent program or system.)

Embodiments described herein relate to determining locks for concurrent software. Such locks may serve to help alleviate the problem precipitated by multiple threads of a concurrent program accessing, utilizing, and/or modifying shared data simultaneously (or nearly simultaneously). Other embodiments described herein relate to acquiring locks determined for a concurrent program during the execution of the program.

<figref idrefs="DRAWINGS">FIG. 2</figref> depicts a flowchart of a method <b>200</b> of acquiring locks within a concurrent program. Such a method may be implemented within the computing system as illustrated by <figref idrefs="DRAWINGS">FIG. 1</figref>. However, although the method <b>200</b> may be implemented on a computing system, it should not be considered to be limited and may extend to implementations on any other suitable platform. The method <b>200</b> includes an act <b>210</b> of identifying an atomic section within the concurrent program. Further, when implemented within computing system <b>100</b>, embodiments described herein may include software <b>106</b> executing on the computing system and may relate to data <b>107</b> which may be shared data within a concurrent program, global data, or may be local data instantiated for a single particular process.

An atomic section is a section of code or a sequence of instructions whose execution should be atomic with respect to other atomic sections of the concurrent program. If a section of code is atomic, then it should appear (although not necessarily be the case) as if the atomic section executed sequentially with respect to all other threads of the program. In other words, if a section is atomic, no interaction or interleaving between that particular atomic section and other atomic sections, threads, or processes within the concurrent program will change the observable behavior or outcome of the program.

For example, an atomic section of the concurrent program may be identified by observing a manual annotation placed by a programmer during coding indicating that a particular code section should be considered atomic. Such an annotation, indicated by the tag primitive “atomic,” is illustrated in Listing 1.

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Listing 1</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>function foo (x, y, z) {</entry></row><row><entry /><entry>  instruction one;</entry></row><row><entry /><entry>  instruction two;</entry></row><row><entry /><entry>  . . .</entry></row><row><entry /><entry>  atomic {</entry></row><row><entry /><entry>    x = y;</entry></row><row><entry /><entry>    z = 100;</entry></row><row><entry /><entry>    . . .</entry></row><row><entry /><entry>  }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Manual annotations by a software developer of which sections of code in a concurrent program should be considered atomic may be advantageous in certain embodiments. Although manual determination of which code sections may be treated as atomic and annotations of atomic sections by programmers during coding can suffice and be advantageous in certain embodiments, such manual annotation should not be considered limiting. An atomic section may also be inferred by an automated process before, during, or after the compilation of a concurrent program. Atomic sections may be determined or specified by other processes, both manual or automatic and may be implemented within a computer process. In embodiments consistent with the principles herein, the indication of an atomic section may be done at any suitable time by any suitable method or process.

The act <b>210</b> of identifying an atomic section may be by observing or accessing a corresponding annotation placed by the programmer during coding. Of course, identifying an atomic section may also be by observing or accessing a corresponding indication which has been provided or created by another suitable process, either manual or automatic. The act <b>210</b> of identifying the atomic section may be by identifying accesses to a data-structure that should happen atomically. The act <b>210</b> of identifying the atomic section may be by any suitable method or process, accessing or observing any suitable indication or data structure, which indicates that a particular code section within a concurrent program should be considered to be atomic.

Once an atomic section has been identified, the method <b>200</b> proceeds to an act <b>220</b> of determining one or more locks to be acquired when executing the atomic section. The one or more locks which are determined may represent a memory location, data, variables, data structures, lists, and/or arrays, and so on which it might be advantageous to protect during the execution of the atomic section. Locks may be determined so that, after the determined locks have been acquired for a particular atomic section, no other thread or atomic section within the concurrent program may access, utilize, and/or modify the memory location, variables, data structures, lists, arrays, and so on, until after the lock acquired during the execution of the atomic section has been released.

In certain embodiments, the locks determined for an atomic section may differ in type depending on whether a memory location, variable, data structure, list, array, and so on, is to be only accessed or is possibly to be written or otherwise modified. It may be appreciated that a lock allowing read-only access to a memory location might be shared in certain embodiments so that other processes may read (but not modify) the memory location. In such an embodiment, a different type of lock may be provided for modify (or write) access to a memory location so that one and only one atomic section may modify a memory location at any given time. Such multiple and differing types of locks are consistent with embodiments as described herein and should be considered to be included in the determination of locks for an atomic section of a concurrent program.

Although the determination of locks for an atomic section may be performed manually by a programmer or analyst, it is advantageous in particular embodiments to perform the act automatically within a computing system.

Locks may be determined for an atomic section by analyzing the shared memory locations that may be accessed, utilized, and/or modified as expressed in terms of expressions valid at the entry of the atomic block. In certain embodiments, this may be done by performing a backward inter-procedural analysis for the atomic section. Such a backward inter-procedural analysis would commence with the last statement within an atomic section and proceed, statement by statement or instruction by instruction, until the beginning of the atomic section is reached. Consider the code example in Listing 1.1.

<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Listing 1.1</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="84pt" align="left" /><colspec colname="1" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>atomic {</entry></row><row><entry /><entry>  int* d = x;</entry></row><row><entry /><entry>  *d = 3;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

In Listing 1.1, it may be desired to protect the shared memory location d. It may be inferred that locking (&amp;(*x)) would protect d by analyzing the code section in a backward fashion in order to determine that acquiring a lock on (&amp;(*x)) suffices to protect d. Such backward analysis may be used to determine the locks required for each shared memory location within an atomic section of a concurrent program.

Now consider the code example given in Listing 1.2.

<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Listing 1.2</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>int*** x, y;</entry></row><row><entry /><entry>int** p;</entry></row><row><entry /><entry>. . .</entry></row><row><entry /><entry>if ( . . . ) {</entry></row><row><entry /><entry>  x = y;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>atomic {</entry></row><row><entry /><entry>  *x = p;</entry></row><row><entry /><entry>  int** w = *y;</entry></row><row><entry /><entry>  int* z = *w;</entry></row><row><entry /><entry>  *z = 3;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

In this analysis, the backward inter-procedural analysis begins by looking at the last statement, *z=3. It may be inferred from this statement that the memory location corresponding to (&amp;(*z)) (immediately before the last statement) needs to be locked at the beginning of the atomic section. (Or, at least, before any instruction affecting the shared memory locations is executed within the atomic section.) Now, moving upwards in the backward analysis, the statement int*z=*w is analyzed. Because z is given in terms of w, it may now be inferred that a sufficient lock required would be one that guards the memory location corresponding to (&amp;(**w)) (immediately before the statement int*z=*w). This, of course, would still give the desired protection of the shared memory location.

Now, continuing in the backward analysis of the code section of Listing 1.2, it is seen that w is given in terms of y. From that expression in the code section, it may now be inferred that a lock that guards the memory location corresponding to (&amp;(***y)) (immediately before the statement int**w=*y) would be sufficient to protect the shared memory location. The protection of (&amp;(***y), as determined from the expression correspondence in the backward inter-procedural analysis of the code section, is sufficient to protect the (potentially) shared memory locations indicated by each of z, w, and y.

The backwards inter-procedural analysis is not yet complete, however. The statement (*x=p;) is now analyzed. From this statement it is inferred that the memory location corresponding to (&amp;(**p) should also be protected by a lock (since x may be aliased with y). Thus, all statements within the atomic section have now been analyzed via the backward inter-procedural analysis. From this analysis, it has been determined that acquiring the locks on (&amp;(**p), (&amp;(***y) is sufficient to protect the shared memory locations accessed, utilized, or modified within the atomic section of Listing 1.2. This analysis may be performed by a compiler or other suitable automated process. In certain embodiments, such analysis may generate a statement such as {acquire (&amp;(**p), (&amp;(***y))} which could then be appropriately inserted into the atomic code section and executed by a run-time library during execution of the concurrent program in order to acquire the appropriate locks. Such insertion of the appropriate acquire statement is illustrated in Listing 1.2.1.

<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Listing 1.2.1</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>atomic {</entry></row><row><entry /><entry>  acquire ( &amp;(**p), (&amp;(***y));</entry></row><row><entry /><entry>    // acquires appropriate locks</entry></row><row><entry /><entry>  *x = p;</entry></row><row><entry /><entry>  int** w = *y;</entry></row><row><entry /><entry>  int* z = *w;</entry></row><row><entry /><entry>  *z = 3;</entry></row><row><entry /><entry>  release( );</entry></row><row><entry /><entry>    // releases locks acquired for this section</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

In order to have an efficient and not excessive list of locks which are to be acquired for an atomic section, particular embodiments will ensure that the locks which are determined for an atomic section are disjoint. This is easily illustrated in terms of a linked list or an array. For an array, within a particular atomic section, it may be determined to acquire a lock on only one particular element of the array. However, in another atomic section it may be determined that every element of the array (or a large number of elements of the array) needs to be protected. If all elements of an array need to be protected, it may be more efficient to acquire a single lock on the array, itself, rather than individual discrete locks on each and every element of the array. In still other atomic sections, at one point in the analysis it may appear that a lock on one element of the array is necessary but, later in the analysis, it may appear that a lock on the entire array is necessary.

Embodiments consistent with the principles described herein may ensure that all the locks determined for an atomic section are disjoint. That is, if it is determined that a lock on an array and a lock on a particular array element are determined to be desired, then the determination of the locks may include the lock on the array and discard the lock on the array element (which the determination knows is included and thereby protected by the parent lock). This is safe because the array element is protected whenever the entire array is protected. In particular embodiments, the determination of locks includes determining if any locks are included in other locks determined and a disjoint set of locks is produced by removing the locks which are included in other locks from the list of locks to be acquired.

Further, the determination of the locks for an atomic section may take into account particular bounds for the number of locks to be acquired for an atomic section. In the array example discussed above, a lock for the entire array may be substituted for a lock on all the elements of the array. In certain embodiments, however, a lock on an entire array may be substituted for a lock on a large number of discrete elements of the array. The particular size or extent of the “large number” should not be considered to be limiting. The bound, above which a “parent” lock is substituted for discrete individual locks, may be set manually by a programmer, by a system administrator, or may be determined by an automated process within a computing system.

In one particular embodiment, a fictitious lock (i.e., an alias) may be substituted for a large number of discrete locks. In this fashion, one lock may serve to lock and provide protection for n discrete elements of an M&gt;n element array A and another lock may serve to lock and provide protection for j elements of the M&gt;j element array A where each of the n discrete elements is different from each of the j elements of the array. Again, as can be appreciated from a review of the information provided herein, the extent or magnitude of “large” should not be considered limiting and may be of different magnitudes in different embodiments or applications of the principles described herein.

It may also be appreciated that such substitution of a parent lock for discrete locks may also be advantageous in the case of unbounded structures. For example, each element of a linked list of unknown size may be locked by such a parent lock. Consider the code example in Listing 1.3.

<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Listing 1.3</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>list* reverse (list* x) {</entry></row><row><entry /><entry>list* y = NULL;</entry></row><row><entry /><entry>atomic {</entry></row><row><entry /><entry>  while ( x != NULL) {</entry></row><row><entry /><entry>    list* t = x −&gt;next;</entry></row><row><entry /><entry>    x−&gt;next = y;</entry></row><row><entry /><entry>    y = x;</entry></row><row><entry /><entry>    x = t;</entry></row><row><entry /><entry>  }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

In this code example, the analysis of the atomic section may indicate that a lock is required to be acquired for x. However, further analysis of the while loop in the atomic section determines that a lock should be acquired for x→next, also. It can be appreciated, that continued analysis of the while loop of the atomic section may indicate that an unbounded acquisition of locks would be required—that is, acquired by the pseudo-statement: <ul><li id="ul0001-0001" num="0000"><ul><li id="ul0002-0001" num="0056">acquire(x, x→next, x→next→next, x→next→next→next, . . . ). <br /> As can be appreciated, this may be impossible to acquire at runtime because the actual extent of the list cannot be known until the actual execution of the atomic section of the concurrent program and so each of the locks indicated in the statement, above, cannot be known when the statement is encountered at runtime. </li></ul></li></ul>

In a fashion similar to that for arrays, a single lock may be acquired in order to protect each element of a possibly unbounded linked list. In certain embodiments, any such unbounded location may be locked by the acquisition of a single parent lock. In the case of the array, discussed above, there may be a particular location (i.e., the head of the array, itself) which can suffice to indicate the lock required to protect the entire structure. However, in the case of a possibly unbounded linked list—whose elements may be spread randomly throughout a heap (or other data or memory repository)—a particular known memory location may not suffice to indicate the required lock. In such cases, in particular embodiments, the determination of locks may provide an alias or fictitious lock which would then serve to indicate a lock on each and every element of the possibly unbounded linked list. This may be similar to the fictitious locks which were used, above, to indicate large numbers of elements from a particular array (without locking all elements of the array) and allowing another fictitious lock to be used to lock other elements of an array.

After the one or more locks have been determined for the atomic section, the method includes an act <b>230</b> of acquiring the one or more locks for the atomic section. In one particular embodiment, the one or more locks which are determined for an atomic section are acquired at the beginning of the atomic section. In another embodiment, each of the one or more locks are acquired within the atomic section prior to the execution of an instruction within the atomic section using a resource subject to any of the one or more locks. In one particular embodiment, the one or more locks determined for an atomic section are acquired by a runtime library during the execution of the concurrent program.

In some embodiments, all the locks which are acquired for an atomic section are acquired based upon some total order. Acquiring locks using a total order is advantageous in order to avoid deadlock between competing threads or atomic sections of a concurrent program. Consider the two functions illustrated in Listing 2.

<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Listing 2</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>function swap1 (int* x, int* y) {</entry></row><row><entry /><entry>  atomic {</entry></row><row><entry /><entry>    int d = *x;</entry></row><row><entry /><entry>    *x = *y;</entry></row><row><entry /><entry>    *y = d;</entry></row><row><entry /><entry>  }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>function swap2 (int* x, int* y) {</entry></row><row><entry /><entry>  atomic {</entry></row><row><entry /><entry>    int d = *y;</entry></row><row><entry /><entry>    *y = *x;</entry></row><row><entry /><entry>    *x = d;</entry></row><row><entry /><entry>  }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

If x and y in the functions swap1 and swap2 of Listing 2 were shared variables and locks were attempted to be acquired for the atomic sections of swap1 and swap2, it is possible that a deadlock may occur. For example, swap1 may attempt to acquire a lock on x and then acquire a lock on y. If swap2 were simultaneously attempting to acquire a lock on y and then x, it is entirely possible that swap1 would acquire a lock on x and swap2 would acquire a lock on y. However, swap1 could not complete until it acquired a lock on y. That lock on y would not be available to swap1 until swap2 proceeded to completion and then released its locks. In this example, swap1 can never complete because swap2 has already acquired the lock on y so swap1 cannot acquire the lock on y which is necessary for completion. Similarly, swap2 cannot complete because it needs to acquire a lock on x before it can complete and release its lock on y. Of course, swap2 cannot acquire the needed lock on x because swap1 has already acquired a lock on x and is waiting for a lock on y.

The above example is a deadlock situation, where one thread or atomic section is waiting for a lock on a resource held by another thread. The other thread or atomic section, similarly, will never complete or release the lock because it, similarly, is waiting for a lock on a resource concurrently held by the first thread or atomic section. In one particular embodiment, the act <b>230</b> of acquiring the one or more locks occurs within the atomic section prior to executing an instruction within the atomic section using a resource subject to the one or more locks. By acquiring each of the one or more locks determined for the atomic section early within the atomic section—i.e., at the beginning of the atomic section or prior to executing any instruction within the atomic section using a resource subject to or associated with the one or more locks—such deadlocks may be avoided.

In certain embodiments, locks which have been determined for an atomic section are sorted before they are acquired and then acquired in an appropriate total order in order to further avoid deadlock. <figref idrefs="DRAWINGS">FIG. 3</figref> illustrates how an appropriate total order may be utilized to prevent such deadlock.

In <figref idrefs="DRAWINGS">FIG. 3</figref>, Total Order <b>310</b> illustrates a total order for possible locks within a particular concurrent program. The nodes of the order trees, <b>310</b> and <b>320</b>, represent the dependencies in the locks to be acquired for the program. Such dependencies may be, as discussed above, a lock for an array (i.e., parent node) and a lock for an element of an array (i.e., child node). Such trees may also represent the fictitious lock which is determined to represent an entire, possibly unbounded, linked list (i.e., parent node) and the individual elements of the linked list (i.e., child nodes).

In this example, Thread <b>1</b><b>335</b> requires locks on nodes <b>2</b> and nodes <b>6</b> before being able to complete execution. However, Thread <b>2</b><b>336</b> requires locks on nodes <b>3</b> and <b>4</b> before successful completion of execution. If Thread <b>1</b> acquires a lock on node <b>2</b>, that lock will also protect the child node <b>4</b>. If Thread <b>2</b> acquires a lock on node <b>3</b>, it will also protect the child node <b>6</b>. This situation would then lead to a deadlock because Thread <b>1</b> is waiting for node <b>6</b> (which is protected by a lock on <b>3</b> by Thread <b>2</b>) and Thread <b>2</b> is waiting for a lock on node <b>4</b> (which is protected by a lock on node <b>4</b> by Thread <b>1</b>).

A different total order, a pre-order, would suffice in certain embodiments to alleviate such a deadlock problem. Pre-Order <b>320</b> illustrates such a pre-order. For this pre-order, all nodes are ordered from the left-most lowest order nodes to the right. The resulting pre-order is illustrated by pre-order <b>320</b>. In this case, thread <b>1</b> may acquire a lock on node <b>3</b> (which, as illustrated protects node <b>1</b>). If it has been determined that thread <b>2</b><b>346</b> requires locks on nodes <b>6</b> and <b>1</b>, then the run-time library sorts the locks to be acquired for that thread (i.e., atomic section) and attempts to acquires the locks on nodes <b>1</b> and <b>6</b>. However, since thread <b>1</b> has already acquired the lock on node <b>3</b>, which protects node <b>1</b>, a lock cannot be acquired by thread <b>2</b> on node <b>1</b> and the acquisition of locks by thread <b>2</b> is postponed until a lock on node <b>1</b> may be available. This will also postpone thread <b>2</b>'s acquisition of a lock on node <b>6</b> which then leaves a lock on node <b>4</b> available for thread <b>1</b> to acquire. Since thread <b>1</b> has now been able to acquire all the necessary locks for its atomic section, it may then successfully complete.

After thread <b>1</b> has completed, it will then release all the locks it had acquired. Once thread <b>1</b> has released its acquired locks, then thread <b>2</b> is able to acquire the locks on node <b>1</b> and node <b>6</b> so that it, too, can execute, complete, and release its acquired locks. Thus, a pre-order can suffice in certain embodiments (whenever the lock dependency graph forms a tree) to prevent deadlocks between atomic sections attempting to acquire locks.

The utilization of a pre-order to prevent deadlock in the acquisition of locks for atomic sections is implemented by determining all the locks required for an atomic section. Once all the locks for an atomic section have been determined, they are sorted by the appropriate total order (i.e., pre-order). Once appropriately sorted, then a run-time library (or other suitable mechanism) may then acquire the determined locks in the sorted order. Utilization of the pre-order and the sorting of the locks to be acquired for an atomic section, particular embodiments provide that all other atomic sections (which are utilizing the same pre-order and sorting mechanism) will appropriately wait for locks and deadlocks will not occur.

While a pre-order suffices to alleviate the deadlock problem, it can also be appreciated that a similar post-order would also suffice to alleviate the deadlock problem (in situations where the lock dependency graph forms a tree). A post-order would be similar to that order illustrated by pre-order <b>320</b> illustrated in <figref idrefs="DRAWINGS">FIG. 3</figref> but will order the nodes from the right-most least order nodes towards the left (not illustrated). Although it has been demonstrated that not all total orders are sufficient to cure the deadlock problem (i.e., Total Order <b>310</b>), but it should be considered that any total order, such as the demonstrated pre-order or a post order (e.g., Pre-Order <b>320</b>), is within the scope of the principles described herein and may be employed within particular embodiments consistent with the principles described herein.

<figref idrefs="DRAWINGS">FIG. 4</figref> depicts a flowchart of a method <b>400</b> of determining one or more locks to be acquired within a concurrent program. Such a method may be implemented within the computing system as illustrated by <figref idrefs="DRAWINGS">FIG. 1</figref>. However, although the method <b>400</b> may be implemented on a computing system, it should not be considered to be limited by that implementation and may extend to embodiments or implementations on any other suitable platform. Further, when implemented within computing system <b>100</b>, embodiments described herein may include software <b>106</b> executing on the computing system and may relate to data <b>107</b> which may be shared data within a concurrent program, global data, or may be local data instantiated for a single particular process.

The method <b>400</b> also includes an act <b>410</b> of identifying an atomic section of the concurrent program. An atomic section is a section of code or a sequence of instructions whose execution should be atomic with respect to other atomic sections of the concurrent program. If a section of code is atomic, then it should appear (although not necessarily be the case) as if the atomic section executed sequentially with respect to all other threads of the program. In other words, if a section is atomic, no interaction or interleaving between that particular atomic section and other atomic sections, threads, or processes within the concurrent program will change the observable behavior or outcome of the program.

As previously described, for example, an atomic section of the concurrent may be identified by observing a manual annotation placed by a programmer during coding indicating that a particular code section should be considered atomic.

Manual annotations by a programmer of which sections of code in a concurrent program should be considered atomic may be advantageous in certain embodiments. Although manual determination of which code sections should be treated as atomic and annotations of atomic sections by programmers during coding can suffice and be advantageous in certain embodiments, such manual annotation should not be considered limiting. An atomic section may also be inferred by an automated process before, during, or after the compilation of a concurrent program. Atomic sections may be determined or specified by other processes, both manual or automatic and may be implemented within a computer process. In embodiments consistent with the principles herein, the indication of an atomic section may be done at any suitable time by any suitable method or process.

The act <b>410</b> of identifying an atomic section may be by observing or accessing a corresponding annotation placed by the programmer during coding. Of course, identifying an atomic section may also be by observing or accessing a corresponding indication which has been provided or created by another suitable process, either manual or automatic. The act <b>410</b> of identifying the atomic section may be by identifying accesses to a data-structure that should happen atomically. The act <b>410</b> of identifying the atomic section may be by any suitable method or process, accessing or observing any suitable indication or data structure, which indicates that a particular code section within a concurrent program should be considered to be atomic.

The method <b>400</b> includes an act <b>420</b> of determining expression correspondence for the atomic section. Such determination of expression correspondence may, in particular embodiments, be implemented within a backward inter-procedural analysis as described above. Determination of expression correspondence includes an analysis of each statement within an atomic section to determine which memory locations correspond to each statement and which expressions correspond to each (possibly) shared memory location for which a lock may be inferred. As described above, the determination of expression correspondence may include a bottom-up inference of which memory locations need to be locked in order to be protected.

At each program point, a set of expressions are determined that indicate the locks that are desirable to protect the memory locations associated with that particular program point. In a particular embodiment, the programming code (or statements) within an atomic section are analyzed in a backward inter-procedural dataflow analysis to determine the expressions that correspond to the memory locations for which locks are desired. Such a backward analysis inspects and analyzes each statement or instruction within an atomic section in a bottom-up fashion in order to determine which memory locations correspond to each statement and which expressions may correspond to each location desired to be locked.

The backward inter-procedural dataflow analysis determines an expression correspondence which can, in certain embodiments, specify a fine grained set of locks. A fine-grained set of locks would correspond to a lock for each (or most) of the discrete memory locations accessed, utilized, and/or modified within the atomic section. As can be appreciated, such a fine grained set of locks may be advantageous to reduce contention within the concurrent program by allowing other atomic sections to proceed without waiting for coarser grained locks to be released by competing atomic sections or threads.

However, a fine grained set of locks, as determined by the backward inter-procedural dataflow analysis and expression correspondence may come with a performance cost which relates to time or resources necessary to acquire a large number of locks or the time or resources necessary to maintain a large list of discrete locks. In particular embodiments, during the backward inter-procedural analysis, if a set of associated discrete locks exceeds some bound K, then a coarser grained lock may be substituted for the discrete locks within the set of determined locks. As discussed above, the coarser grained locks may be determined by a points-to analysis (as in the case of the array) or may be a fictitious lock determined and maintained to represent an associated set of finer grained discrete locks.

As discussed above, it may be advantageous to determine locks not necessarily for discrete memory locations associated with an atomic section. In the case of the array, as discussed above, a points-to analysis may be utilized to determine a coarser grained set of locks which will result in a set of locks including locks which protect a multiplicity of memory locations associated with the atomic section.

The method <b>400</b> also includes an act <b>430</b> of determining a set of one or more locks to be acquired for the atomic section from the expression correspondence. As discussed above, particular embodiments may determine a discrete lock for each memory location associated with an atomic section. The locks determined for the atomics section may, in other embodiments, be bounded by some particular limit.

The set of one or more locks which are determined for an atomic section may be sorted and ordered, as discussed above, according to some appropriate total order. Such a total order may be a pre-order or a post-order or any other appropriate order such that, if the locks are acquired at the beginning of an atomic section (or within the atomic section before any instruction subject to any of the locks within the determined set of locks) the order of the locks serves to avoid deadlock.

As discussed above, within particular embodiments, the set of locks which are determined for an atomic section are disjoint. In other words, no lock within the set of determined locks would be subject to or protected by another lock within the determined set. If a lock within the determined set of locks would be protected by another lock in the set, then the finer grained lock may be removed from the set.

<figref idrefs="DRAWINGS">FIG. 5</figref> depicts a flowchart of a method <b>500</b> of determining one or more locks to be acquired for an atomic section within a concurrent program. Such a method may be implemented within the computing system as illustrated by <figref idrefs="DRAWINGS">FIG. 1</figref>. However, although the method <b>500</b> may be implemented on a computing system, it should not be considered to be limited by that implementation and may extend to embodiments or implementations on any other suitable platform. The method <b>500</b> may also be implemented as a computer program product comprising one or more computer-readable media upon which are encoded instructions which, when executed on suitable computing equipment, execute the method <b>500</b> of determining one or more locks to be acquired for an atomic section within a concurrent program.

The method <b>500</b> includes an act <b>510</b> of identifying an atomic section of the concurrent program. As above, the act <b>510</b> of identifying an atomic section may be by observing or accessing a corresponding annotation placed by the programmer during coding. Of course, identifying an atomic section may also be by observing or accessing a corresponding indication which has been provided or created by another suitable process, either manual or automatic. The act <b>510</b> of identifying the atomic section may be by identifying accesses to a data-structure that should happen atomically. The act <b>510</b> of identifying the atomic section may be by any suitable method or process, accessing or observing any suitable indication or data structure, which indicates that a particular code section within a concurrent program should be considered to be atomic.

The method <b>500</b> includes an act <b>520</b> of determining one or more fine grained locks for the atomic section. In certain embodiments, the act <b>520</b> of determining one or more fine grained locks for the atomic section proceeds through a backward inter-procedural data analysis. Such back backward inter-procedural dataflow analysis, in particular embodiments, would employ expression correspondence to determine a fine grained set of locks which, when appropriately acquired, would serve to protect each discrete memory location accessed, utilized, and/or modified within the atomic section.

The method <b>500</b> also includes an act <b>530</b> of determining if the number of the fine grained locks determined for the atomic section exceed a certain particular bound. As discussed above, the exact extent or magnitude of the bound should not be considered limiting as any particular bound—as determined manually, arbitrarily set, or automatically derived—is consistent with the principles disclosed herein.

The method <b>500</b> includes an act <b>540</b> of determining alternative locks such that all previously determined fine grained locks are covered and the locks do not exceed the particular bound. As illustrated in <figref idrefs="DRAWINGS">FIG. 5</figref>, the act <b>540</b> of determining alternative locks may not necessarily be performed every time the method <b>500</b> is performed. Method <b>500</b> includes an act <b>530</b> of determining if the set of the locks determined for the atomic section exceed some bound. If the set of locks exceeds the bound, then the method proceeds to the act <b>540</b> of determining alternative locks such that the locks would not exceed the particular bound.

As discussed above, the particular bound should not be considered limiting. Any bound of any extent or magnitude, whether determined by an automated process or arbitrarily or manually set would be consistent with the principles as described herein.

The alternative locks which are determined in act <b>540</b> may, in particular embodiments, come from points-to analysis. Such an analysis can be used to determine a parent lock such that a single lock can serve to lock all the elements on an array. Such an analysis may also serve to determine a single lock which may serve to lock all the elements of a linked list. Such a points-to analysis may also serve to lock and protect another suitable group of finer grained or discrete locks.

The alternative locks are not, however, limited to those which may be determined by a points-to analysis. In particular embodiments, the alternative locks may be fictitious locks (i.e., aliases) which may serve to lock a particular set of discrete locks. For example, such a fictitious lock may be based on type information already present in the source code of the concurrent program and may be used to lock a possibly unbounded linked list or some other data structure which may not be completely knowable at compile time or during runtime before the particular atomic section has run.

In various embodiments, the locks determined for an atomic section may include a number of fine grained locks and a number of alternative coarser grained locks which were determined after a bound were reached for some subset of the finer grained locks. In other embodiments, all locks determined for an atomic section may be fine grained locks. In still other embodiments, all fine grained locks may have been supplanted by one or more alternative coarser grained alternative locks. It should be appreciated from review of the present disclosure that no particular distribution of fine grained or alternative coarser grained locks is necessary to be consistent with the principles disclosed herein.

In various embodiments, the alternative coarser grained locks may be represented by group level locks. A group level lock is a single lock (i.e., a parent lock) which represents a plurality of locks (i.e., child locks). Such group level locks may be graphically depicted by the Total Order <b>310</b> and Pre-Order <b>320</b> trees of <figref idrefs="DRAWINGS">FIG. 3</figref>. In the Pre-Order <b>320</b> tree of <figref idrefs="DRAWINGS">FIG. 3</figref>, node <b>3</b> may be considered a group level lock and nodes <b>1</b> and <b>2</b> may be considered child locks. Such child locks may be location level locks which have an actual address within a computing systems memory space or they, themselves, may also be group level locks which, like node <b>3</b>, have additional child locks.

Group level locks may be actual locations, as the head of an array, or they may be represented by fictitious locks which are maintained during runtime to represent some (possibly unbounded) set of child locks. When a group level lock is maintained as a fictitious lock, it may be maintained and serviced in any appropriate data structure by the runtime process which services and maintains the locking system. The exact nature of the system used to maintain the locks, both location level locks, and coarser grained or group level locks, should not be considered limiting to the principles herein and any suitable system should be considered to be consistent.

As previously discussed, in particular embodiments, both the fine grained locks and the alternative coarser grained alternative locks may be sorted and/or acquired according to an appropriate total order. Such an appropriate total order may be a pre-order or a post-order or any other suitable total order useful to avoid deadlock during the acquisition of the locks or the execution of an atomic section. In one particular embodiment, the locks are determined such that they can be acquired during runtime at the entrance (i.e., the beginning) of the atomic section. In another embodiment, the locks are determined such that they can be acquired at some time within the atomic section prior to the execution of any instruction within the atomic section associated with a protected data structure to be protected by any lock in the one or more locks determined.

The principles described herein may be embodied in other specific forms without departing from the spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the embodiments described herein are, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.