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

Definitions

• Transactional memory is designed to ease development of concurrent programs by providing atomicity and isolation to regions of program code.
• Transactional memory 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.
• TM is used as an alternative to traditional locking mechanisms.
• TM allows concurrent programs to be written more simply.
• a transaction specifies a sequence of code that is supposed to execute as if it were executing in isolation, whereas in reality it executes in a normal multithreaded environment with many concurrent activities.
• This illusion of isolation may be achieved by fine-grained locking of objects or memory ranges, and by executing in a mode that allows the effects of the transaction to be rolled back if the transaction is discovered to be in conflict with some other transaction. We say that a data access is "transacted" if the access is protected by these locking and rollback mechanisms.
• Different locking and versioning mechanisms are possible, including several software-based and hardware-based approaches. Different mechanisms have features and qualities making each suitable or preferable in different situations. Combining different mechanisms within a single process generally is not possible, leading to the selection of generic mechanisms which typically compromise on performance in order to achieve general applicability.
• the transaction grouping feature is operable to allow transaction groups to be created that contain related transactions.
• the transaction groups are used to enhance operation of the programs.
• Transaction groups are defined such that the transactions in each group are known to operate on disjoint data, which enables incompatible locking and versioning mechanisms within each such group, in turn allowing fine-tuning of the specific mechanisms for each particular group.
• 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
• FIG. 1 illustrating the stages involved in allowing a programmer to group transactions.
• Figure 5 is a process flow diagram for one implementation of the system of Figure 1 illustrating the stages involved in providing a language compiler that automatically groups transactions based on specific heuristics.
• Figure 6 is a process flow diagram for one implementation of the system of Figure 1 illustrating the stages involved in providing a runtime environment that automatically groups transactions.
• Figure 7 is a process flow diagram for one implementation of the system of Figure 1 that illustrates the stages involved in providing specialized contention management for different transaction groups.
• Figure 8 is a process flow diagram for one implementation of the system of Figure 1 that illustrates the stages involved in providing specialized locking and versioning mechanisms for different transaction groups.
• Figure 9 is a process flow diagram for one implementation of the system of Figure 1 that illustrates the stages involved in naming a grouping of related transactions to enhance debugging or other processes.
• Figure 10 is a diagrammatic view of multiple transaction groups.
• a transaction grouping feature is provided for use in programs operating under a transactional memory system. The transaction grouping feature allows transactions to be placed into groups.
• transactions that are part of a group are known to operate on read/write data which is disjoint from the read/write data accessed by other transactions within other groups.
• it becomes possible to implement distinct locking and versioning mechanisms for each such group allowing each transaction group to leverage specially-selected locking and versioning algorithms most appropriate for the data accessed by the transactions in the group.
• Determining when transactions can be grouped can be accomplished through a plurality of means.
• One implementation may leverage programmer-supplied annotations to demark the groups, as described in Figure 4.
• Another implementation may use compiler heuristics to automatically infer groups and group membership, as described in Figure 5.
• Still another implementation may use a runtime environment to dynamically and automatically infer groups and group membership, as described in Figure 6. It should be appreciated that the specific mechanisms involved in creating groups and assigning group membership are many and can be combined in various ways.
• 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.
• 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 is one of the application programs that reside on computing device 100. However, it will be understood that 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. Alternatively or additionally, 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 transaction grouping feature that allows related transactions in a particular program to be grouped together 206 (as described below with respect to Figures 3-6); logic for providing specialized contention management using transaction groups 210 (as described below with respect to Figure 7); logic for providing different locking and versioning mechanisms for different transaction groups 212 (as described below with respect to Figure 8); logic for naming a transaction group to enhance debugging or other processes 214 (as described below with respect to Figure 9); and other logic for operating the transactional memory application 220.
• FIG. 3 is a high level process flow diagram for transactional memory application 200.
• the process begins at start point 240 with providing a transactional memory system using software, hardware, and/or combinations thereof (stage 242).
• stage 242 The system provides a transaction grouping feature that allows related transactions in a particular program to be grouped together either manually (as described in Figure 4), and/or programmatically (as described in Figures 5 and 6) (stage 244).
• FIG. 4 illustrates one implementation of the stages involved in allowing a programmer to group transactions.
• the process begins at start point 270 with receiving input from a programmer to access the source code of a particular program that executes under a transactional memory system (stage 272).
• the programmer adds declarations or otherwise assigns groups to transactions (stage 274).
• the system uses the specified groups to enhance program operation, as described in further detail in Figures 7-9 (stage 276).
• stage 276 The process ends at end point 278.
• FIG. 5 illustrates one implementation of the stages involved in providing a language compiler that automatically groups transactions.
• the process begins at start point 290 with providing a language compiler for compiling programs that execute under a transactional memory system (stage 292).
• stage 292 At compile time of a particular program, logic is used to determine if any transactions may be grouped together (stage 294).
• transactions may be grouped together by a compiler by leveraging the particular semantics of the programming language or through global analysis that demonstrates that groups are possible.
• the system creates the identified groups in the program (stage 296) and then uses the specified groups to enhance the program operation (stage 298).
• stage 298 uses the specified groups to enhance the program operation
• the process begins at start point 310 with providing a runtime environment for running programs under a transactional memory system (stage 312).
• logic is used to identify transactions that should be grouped together (stage 314).
• transactions may be grouped together by a runtime environment by identifying sets of transactions which must by construction operate on disjoint read/write data.
• the runtime may operate on hints supplied by the compiler to hone its analysis process.
• the runtime groups the identified transactions together (stage 316) and uses the grouped transactions to improve operation of the particular program (stage 318).
• the process ends at end point 320.
• FIG. 7 illustrates one implementation of the stages involved in providing specialized contention management using grouped transactions.
• the process begins at start point 340 with allowing one or more specialized contention management policies to be defined by a programmer (stage 342). For each policy, the system allows transaction execution scheduling settings, transaction abort handling settings, and/or other settings to be specified (stage 344). The previously defined policy can then be assigned to each transaction group in a process (stage 346). The system uses the policies to implement specialized contention management for the grouped transactions (stage 348).
• Contention management is the mechanism used by a runtime system to select appropriate behavior whenever a conflict is detected between multiple concurrently executing transactions. Contention management decides which of the conflicting transactions, if any, to preserve and which to abort. It further decides how to reschedule execution of the individual transactions such that they can run to completion. Specialized contention management as used herein refers to the ability to apply contention management heuristics which are distinct from the default heuristics of a given runtime. [032] In one implementation, by applying different policies to different groups, enhanced performance of the program can be achieved. For example, one type of specialized contention management policy can be assigned to a particular transaction group that will give the best performance for the types of operations those transactions contain. Another specialized contention management policy can be assigned to another transaction group that will get the best performance for the types of operations that the other transaction group contains. The process ends at end point 350.
• Figure 8 illustrates one implementation of the stages involved in providing different locking and versioning mechanisms for different groups of transactions.
• the process begins at start point 370.
• the system uses logic to determine what type of locking and versioning to use for each transaction group (stage 372) and then adjusts the locking and versioning used on each transaction group as necessary (stage 374).
• stage 372 uses logic to determine what type of locking and versioning to use for each transaction group
• stage 374 uses logic to determine what type of locking and versioning to use for each transaction group
• stage 374 the locking and versioning used on each transaction group as necessary
• stage 374 the locking and versioning used on each transaction group as necessary
• stage 374 the locking and versioning used on each transaction group as necessary
• stage 374 the locking and versioning used on each transaction group as necessary
• stage 374 the locking and versioning used on each transaction group as necessary
• stage 374 sets the locking and versioning used on each transaction group as necessary
• stage 374 sets the locking and versioning used on each transaction group as necessary
• stage 374 sets the locking
• FIG. 9 illustrates one implementation of the stages involved in naming a grouping of related transactions to enhance debugging or other processes.
• the process begins at start point 450 with allowing related transaction to be grouped together by a user and/or programmatically (stage 452).
• a naming feature is provided that allows each transaction group to be given a name by a user and/or programmatically (stage 454).
• the system then displays or uses the group names to enhance debugging, profiling, or other processes (stage 456).
• Figure 10 is a diagrammatic view of multiple transaction groups.
• a first transaction group 500 contains four transactions, one of which is nested within the other.
• the second transaction group 502 just contains a single transaction. Numerous other transactional grouping scenarios are also possible that contain a different number of transaction groups and/or a different number of transactions within each group.

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Executing Machine-Instructions (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Debugging And Monitoring (AREA)
• Memory System Of A Hierarchy Structure (AREA)
• Devices For Executing Special Programs (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (2)

Family

ID=40161867

Family Applications (1)

Country Status (6)

Cited By (1)

Families Citing this family (17)

Family Cites Families (52)

• 2007
  • 2007-06-29 US US11/824,379 patent/US7941411B2/en active Active
• 2008
  • 2008-06-18 WO PCT/US2008/067343 patent/WO2009006023A2/en not_active Ceased
  • 2008-06-18 JP JP2010514980A patent/JP5328055B2/ja not_active Expired - Fee Related
  • 2008-06-18 EP EP08771364.0A patent/EP2176763B1/en active Active
  • 2008-06-18 CN CN2008800201893A patent/CN101681294B/zh not_active Expired - Fee Related
  • 2008-06-24 TW TW097123601A patent/TWI442235B/zh not_active IP Right Cessation
• 2011
  • 2011-03-08 US US13/043,082 patent/US8484175B2/en not_active Expired - Fee Related

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events