Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/466—Transaction processing
  • G06F9/467—Transactional memory
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F8/00—Arrangements for software engineering
  • G06F8/30—Creation or generation of source code
  • G06F8/31—Programming languages or programming paradigms
  • G06F8/314—Parallel programming languages

Definitions

• STM Software transactional memory
• STM is a concurrency control mechanism analogous to database transactions for controlling access to shared memory in concurrent computing.
• a transaction in the context of transactional memory is a piece of code that executes a series of reads and writes to shared memory.
• STM is used as an alternative to traditional locking mechanisms.
• Programmers put a declarative annotation (e.g., atomic) around a code block to indicate safety properties they require and the system automatically guarantees that this block executes atomically with respect to other protected code regions.
• the software transactional memory programming model prevents lock-based priority-inversion and deadlock problems.
• STM Software transactional memory
• the source code for these sequential programs is typically written by programmers using one of various types of programming languages.
• the source code is typically enclosed in one or more functions that contain the logic that is later executed by a computer.
• the term "function" is used broadly herein as covering functions, methods, procedures, statement blocks, and/or other portions of logic that are executed by a computer.
• Various technologies and techniques are disclosed for creating and/or locating transactional code blocks in a transactional memory system.
• a user such as a software developer can decorate a particular function with an identifier to indicate that the particular function is transaction-safe.
• a normal version and a transactional version are then created for each function of a software application that is marked as transaction-safe.
• a normal version is created for each function that is not marked as transaction-safe.
• a stub pointer in the normal version is pointed to the transactional version. The proper version of the function is then called depending on the application context.
• a compiler generates the transactional and non- transactional version of the functions for use with the transactional memory system.
• a stub pointer is allocated for each function in a software application.
• a normal version of the respective function is generated, and the stub pointer is filled in with an entry point of a runtime error routine.
• code is created for a normal version and a transactional version of the respective function that is transaction-safe. Then, in the stub pointer for the normal version, an entry point is filled to the transactional version.
• an entry point is filled to the runtime error routine.
• Figure 1 is a diagrammatic view of a computer system of one implementation.
• Figure 2 is a diagrammatic view of a transactional memory application of one implementation operating on the computer system of Figure 1.
• Figure 3 is a high-level process flow diagram for one implementation of the system of Figure 1.
• Figure 4 is a process flow diagram for one implementation of the system of Figure 1 illustrating the stages involved in using a code generator to generate code for transactional and non-transactional function and fill in the stub pointers as part of the compile and/or linking process.
• Figure 5 is a diagram for one implementation of the system of Figure 1 illustrating the decision tree for choosing the proper version of the function to call depending on execution context.
• Figure 6 is a logical diagram for one implementation that illustrates two hypothetical functions, one with just a normal version and the other with a normal version and a transactional version.
• the system may be described in the general context as a transactional memory system, but the system also serves other purposes in addition to these.
• one or more of the techniques described herein can be implemented as features within a framework program such as MICROSOFT® .NET Framework, or from any other type of program or service that provides platforms for developers to develop software applications.
• one or more of the techniques described herein are implemented as features with other applications that deal with developing applications that execute in concurrent environments.
• a transactional memory system programmatically creates two versions of each function that is marked as transaction-safe: a normal version of the function and a transactional version of the function. For functions that are not marked as transaction safe, only a normal version is created and a stub pointer at the entry point of the normal version is pointed to an error routine. Then, for functions that are marked as transaction-safe, a stub pointer of the entry point of the normal version is pointed to the transactional version of the function. A stub pointer at the entry point of the transactional version is pointed to an error routine. For functions that are not marked as transaction-safe, the stub pointer at the entry point of the normal version points to the error routine. The proper version of the function is then called depending on the execution context.
• an exemplary computer system to use for implementing one or more parts of the system includes a computing device, such as computing device 100.
• computing device 100 In its most basic configuration, computing device 100 typically includes at least one processing unit 102 and memory 104. Depending on the exact configuration and type of computing device, memory 104 may be volatile (such as RAM), non- volatile (such as ROM, flash memory, etc.) or some combination of the two. This most basic configuration is illustrated in Figure 1 by dashed line 106.
• device 100 may also have additional features/functionality. For example, device 100 may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape.
• Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
• Memory 104, removable storage 108 and nonremovable storage 110 are all examples of computer storage media.
• Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by device 100. Any such computer storage media may be part of device 100.
• Computing device 100 includes one or more communication connections 114 that allow computing device 100 to communicate with other computers/applications 115.
• Device 100 may also have input device(s) 112 such as keyboard, mouse, pen, voice input device, touch input device, etc.
• Output device(s) 111 such as a display, speakers, printer, etc. may also be included. These devices are well known in the art and need not be discussed at length here.
• computing device 100 includes transactional memory application 200. Transactional memory application 200 will be described in further detail in Figure 2.
• transactional memory application 200 operating on computing device 100 is illustrated.
• Transactional memory application 200 is one of the application programs that reside on computing device 100.
• transactional memory application 200 can alternatively or additionally be embodied as computer- executable instructions on one or more computers and/or in different variations than shown on Figure 1.
• one or more parts of transactional memory application 200 can be part of system memory 104, on other computers and/or applications 115, or other such variations as would occur to one in the computer software art.
• Transactional memory application 200 includes program logic 204, which is responsible for carrying out some or all of the techniques described herein.
• Program logic 204 includes logic for providing a transactional memory system 206; logic for allowing a user/developer to decorate functions of a software application with an attribute or other identifier to indicate the function is transaction-safe 208; logic for creating two versions (e.g., a normal version and a transactional version) for each function that is marked as transaction-safe 210; logic for creating one version (e.g., a normal version) for each function that is not marked as transaction- safe 212; logic for allocating a stub pointer for each function (e.g., before the beginning of the code section or other place) 214; logic for making the stubs point to the right places (e.g., the transactional version or the runtime error routine) 216; and other logic for operating the application 220.
• Program logic 204 includes logic for providing a transactional memory system 206; logic for allowing a user/developer
• FIG. 3 is a high level process flow diagram for transactional memory application 200.
• the process of Figure 3 is at least partially implemented in the operating logic of computing device 100.
• the process begins at start point 240 with providing a transactional memory system (e.g., a software transactional memory system) (stage 242).
• a transactional memory system e.g., a software transactional memory system
• stage 242 The system allows a user/developer to decorate a particular function with an attribute or other identifier to indicate the function is transaction-safe (stage 244).
• the compiler and/or linker create two versions of the particular function: one for use without transactions (e.g., the normal version) and one for use with transactions (e.g., the transactional version) (stage 246).
• the system stores a stub pointer points to the transactional version of the particular function (stage 248).
• the stub pointer(s) described herein are stored before the respective compiled function body text.
• the stub pointer can be stored in other locations, so long as it is associated with a respective version of the function.
• the system stores a stub pointer that points to a runtime error routine (stage 249).
• the proper version of the function is called depending on execution context (stage 250). The process ends at end point 252.
• Figure 4 illustrates one implementation of the stages involved in using a code generator to generate code for transactional and non-transactional functions and to fill in the stub pointers as part of the compile/and or linking process.
• the process of Figure 4 is at least partially implemented in the operating logic of computing device 100.
• the process begins at start point 270 with the code generator allocating an extra pointer (e.g., the stub pointer) for each function at compile time (stage 272). For each function (i.e., while there are more functions) (decision point 274), various tasks are performed.
• the system For example, if the function is not marked as being a transaction-safe function (decision point 276), then the system generates the normal version (i.e., regular code) for the function, and fills in the stub pointer of the normal version with the entry point of the runtime error routine (stage 286).
• the normal version i.e., regular code
• the system creates code for the normal version F and its transactional version FT (stage 278).
• the system allocates a stub pointer for the transactional version and the normal version of the function F (stage 280).
• the entry point of the transactional version is filled (stage 282).
• the entry point of a runtime error routine is filled (stage 284).
• FIG. 5 a diagram 300 for one implementation of the system of Figure 1 illustrates a possible decision tree for choosing the proper version of the function to call depending on execution context.
• the decision process of Figure 5 is at least partially implemented in the operating logic of computing device 100.
• the entry point of the normal version is called directly for the function 312.
• the entry point of the transactional version is called for the function 314.
• the call is the same as before 316.
• a pointer call 308 in a transactional context 304 For a pointer call 308 in a transactional context 304, the address of the word pointing to the stub function is computed from the dereference of the function pointer value and then that address is used in the call 318. The stub is populated with a pointer to entry point of the transactional version and therefore the correct version is executed.
• a virtual or interface call 310 in a non-transactional context 302 is not affected, and is the same as before 320.
• a virtual or interface call 310 in the transactional context 304 performs the vtable lookup and then computes the stub function entry point of the transactional version of the function 322. The computed entry point is then used to make the call.
• FIG. 6 is a logical diagram 400 for one implementation that illustrates two hypothetical functions, one with just a normal version and the other with a normal version and a transactional version.
• the "BAR" function 402 is a function that was not marked as transaction-safe in the source code.
• the entry pointer 412 to the function 402 points to the error routine 410.
• the "FOO" function 414 was marked as transaction-safe in the original source code, so a normally compiled version (the normal version) is provided 406, along with the transactional version 408.
• the entry point 414 of the normal version of FOO 406 points to the transactional version of FOO 408.
• the entry point 416 of the transactional version of FOO 408 points to the error routine 410.
• this error routine is embedded in the stubs (entry points) of these functions to allow errors to be caught at runtime when inappropriate use is encountered.

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• General Engineering & Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Computing Systems (AREA)
• Stored Programmes (AREA)
• Devices For Executing Special Programs (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Priority Applications (4)

Applications Claiming Priority (2)

Publications (2)

Family

ID=40089759

Family Applications (1)

Country Status (6)

Families Citing this family (3)

Family Cites Families (18)

• 2007
  • 2007-06-01 US US11/809,514 patent/US8006227B2/en active Active
• 2008
  • 2008-05-30 CN CN2008800184811A patent/CN101681293B/zh active Active
  • 2008-05-30 BR BRPI0810468-9A2A patent/BRPI0810468A2/pt not_active IP Right Cessation
  • 2008-05-30 JP JP2010510519A patent/JP5276094B2/ja not_active Expired - Fee Related
  • 2008-05-30 EP EP08769895.7A patent/EP2171591B1/en active Active
  • 2008-05-30 WO PCT/US2008/065312 patent/WO2008151013A2/en not_active Ceased

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events