Thread synchronization methods and apparatus for managed run-time environments

#This disclosure relates generally to computers and, more particularly, to thread synchronization methods and apparatus for managed run-time environments.

#Software environments that support multithreaded applications, for example, JAVA and the European Computer Manufacturers Association (ECMA) Common Language Infrastructure (CLI), typically include a synchronization mechanism for coordinating when one or more threads may access an object. As will be appreciated by those of ordinary skill in the art, a thread refers to a series of processor instructions organized into a single control flow of execution for processing one or more objects. An object is an instance of a class, where a class is a collection of data and methods to operate on such data. In the case of multiple threads of execution, care must be taken to prevent the multiple threads from modifying the same object simultaneously in a way that might place the object in an erroneous state. In particular, a thread may have critical sections that operate on objects that could be accessed simultaneously by another thread. Thus, multithreaded systems typically provide specialized statements to protect the operation of a critical section from being corrupted by one or more other threads accessing such a shared object during critical section execution.

#For example, JAVA source code may include a synchronized statement to protect objects from being accessed simultaneously by different threads. Use of the synchronized statement enables acquisition of an exclusive lock of an object identified by the synchronized statement. Thus, a thread may be prevented from executing a critical section of code until it can obtain an exclusive lock on a particular object identified by a synchronized statement. Moreover, once such a lock is obtained, no other thread can access the locked object, thereby preventing inadvertent corruption of the processing being performed during execution of a critical section of code. Such a locking procedure may be used to ensure that multiple threads cannot access shared objects in a manner that could cause conflicting execution of critical sections of code at the same time. Of course, application of the synchronized statement is generally used in cases where a particular program creates multiple threads to share objects and/or methods. If only one thread ever accesses a particular object and/or method, there is no need to protect it with a synchronized statement.

#FIG. 1 is a block diagram of an example managed run-time environment in which the example methods, apparatus and articles of manufacture described herein may be employed.

#FIG. 2 is a block diagram of an example lock manager that may be used in the managed run-time environment of FIG. 1.

#FIGS. 3A-3B are flowcharts representative of example machine readable instructions that may be executed by a machine to implement an example prior-art lock manager that may be used in the managed run-time environment of FIG. 1.

#A block diagram of an example environment of use 100 in which the example methods, apparatus and articles of manufacture described herein may be employed is illustrated in FIG. 1. The example environment of use 100 may be implemented, for example, via one or more processor systems such as the example processor system 1100 of FIG. 11 described below. While the example of FIG. 1 corresponds to a JAVA-based managed run-time environment (MRTE), one having ordinary skill in the art will appreciate that the example methods, apparatus and articles of manufacture described herein may be applied to any similar MRTE environment of use, such as, for example, CLI and the associated language C#.

#The example environment of use 100 includes an MRTE depicted as a JAVA virtual machine (JVM) 110 in FIG. 1. The example JVM 110 dynamically converts a program represented by machine-independent instructions, or bytecodes 114, into machine-dependent, or native, instructions and then executes the native instructions on one or more processors 120 (such as the processor 1112 discussed below). The JVM 110 may execute the native instructions via an operating system (OS) 130 specific to the one or more processors 120, such as the Microsoft Windows OS, the UNIX OS, the Linux OS, etc.

#In the example of FIG. 1, the JVM 110 processes bytecodes 114 that are stored in a plurality of classfiles 114. Typically, a classfile 114 stores bytecodes 114 corresponding to a single JAVA class, including the interfaces, fields and methods that define the class. A classfile 114 may be created by a JAVA compiler 134 from JAVA program source code 138 written, for example, by a software developer. The JAVA compiler 134, the associated JAVA source code 138 and the resulting classfiles 114 (or bytecode 114) are well-known in the art and are not discussed further herein.