Patent Grant
7703098
This application is related to commonly-owned U.S. patent application Ser. No. 10/894,829, entitled “Using Transactional Memory with Early Release to Implement Non-Blocking Dynamic-Sized Data Structure,” naming Mark S. Moir and Maurice Herlihy as inventors, and filed on even date herewith.
The application is also related to the following commonly-owned co-pending U.S. patent applications: application Ser. No. 10/439,911, filed 16 May 2003, now U.S. Pat. No. 7,216,202, which issued May 8, 2007, entitled “Method and Apparatus for Avoiding Locks by Speculatively Executing Critical Sections” and naming Shailender Chaudhry, Marc Tremblay and Quinn A. Jacobson as inventors; application Ser. No. 10/764,412, filed 23 Jan. 2004, now U.S. Pat. No. 7,089,374, which issued on Aug. 8, 2006, entitled “Selectively Unmarking Load-Marked Cache Lines during Transactional Program Execution” and naming Marc Tremblay, Quinn A. Jacobson, Shailender Chaudhry, Mark S. Moir and Maurice Herlihy as inventors; U.S. Pat. No. 7,206,903, which issued on Apr. 17, 2007, entitled “Method and Apparatus for Releasing Memory Locations During Transactional Execution” and naming Mark S. Moir, Maurice P. Herlihy, Quinn A. Jacobson, Shailender Chaudhry, and Marc Tremblay as inventors; and application Ser. No. 10/621,072, filed Jul. 16, 2003, entitled “Software Transactional Memory for Dynamically Sizable Shared Data Structures,” and naming Mark S. Moir, Victor M. Luchangco and Maurice Herlihy as inventors, now U.S. Pat. No. 7,328,316, which issued Feb. 5, 2008.
1. Field of the Invention
The present invention relates generally to coordination amongst execution sequences in a multiprocessor, and more particularly, to techniques for coordinating access to a transactional memory space.
2. Description of the Related Art
In concurrent software designs and implementations, it is often important to ensure that one thread does not observe partial results of an operation that is concurrently being executed by another thread. Such assurances are important for practical and productive software development because, without them, it can be extremely difficult to reason about the interactions of concurrent threads.
Such assurances have often been provided by using locks to prevent other threads from accessing the data affected by an ongoing operation. Unfortunately, the use of locks gives rise to a number of well known problems, both in terms of software engineering and in terms of performance. First, the right “balance” of locking must be achieved, so that correctness can be maintained, but the use of a particular lock does not prevent access to an unnecessary amount of unrelated data (thereby causing other threads to wait when they do not have to). Furthermore, if not used carefully, locks can result in deadlock, causing software to freeze up. While well documented, these and other problems are pervasive in concurrent programming, and addressing them often results in code that is complicated and expensive.
A further limitation exhibited by software that employs locks as a coordination mechanism is that, no matter how carefully used, lock implementations typically have the problem that if a thread is delayed (e.g., preempted) while holding a lock, then other threads must wait for at least the duration of that delay before being able to acquire that lock. In general, operating systems and other runtime environments cannot avoid this problem because they cannot accurately predict how long a particular lock will be held, and they cannot revoke the lock without jeopardizing correctness.
Transactional memory is a paradigm that allows the programmer to design code as if multiple memory locations can be accessed and/or modified in a single atomic step. As typically defined, a transactional memory interface allows a programmer to designate certain sequences of operations as “transactions,” which are guaranteed by the transactional memory implementation to either take effect atomically and in their entirety (in which case we say they succeed), or have no externally visible effect (in which case we say that they fail). Thus, in many cases, it is possible to complete a multi-target operation with no possibility of another thread observing partial results, even without holding any locks. The transactional paradigm can significantly simplify the design of concurrent programs.
In general, transactional memory can be implemented in hardware, with the hardware directly ensuring that a transaction is atomic, or in software that provides the “illusion” that the transaction is atomic, even though in fact it is executed in smaller atomic steps by the underlying hardware. See e.g., M. Herlihy and J. Moss, Transactional Memory Architectural Support for Lock-Free Data Structures, In Proceedings of the 20th International Symposium in Computer Architecture, pp. 289-300 (1993); N. Shavit and D. Touitou, Software Transactional Memory, Distributed Computing, Special Issue (10):99-116 (1997).
Transactional memory is widely recognized as a promising paradigm for allowing a programmer to make updates to multiple locations in a manner that is apparently atomic, while addressing many of the problems associated with the use of locks. However, certain classes of algorithms and concurrent shared objects may not be well suited to transaction memory, at least as conventionally defined. For example, transactional operations on dynamically-sized data structures (e.g., lists, trees, etc.) may not be well-suited given the substantial working set exposure accumulated in traversal of large structures. Similarly, transactional operations that perform significant computations but which can fail on a condition (e.g., buffer full) whose eventual removal or satisfaction does not necessarily undermine the validity of the prior computations, may not be well-suited to transaction memory, as conventionally defined. Accordingly, modifications to the transactional interface and corresponding exploitations for concurrent software and shared objects are desired.
Transactions may invest significant computational effort, e.g., processing information read from locations that form at least part of a read set of the transaction. However, for some transactional sequences and some states of the transactional memory space, all that effort may be for naught, because a simple condition remains unsatisfied at the instant the transaction attempts to complete (and thereafter commit). For example, an output buffer may be full. A general motivating example is a transaction that removes (e.g., dequeues, pops, cuts, etc.) an item from one data structure (e.g., a queue, stack, tree, etc.), processes it somehow and introduces a result into a target data structure. If the target data structure cannot receive the result, e.g., because it is full, then in a conventional transactional memory, the transaction aborts and restarts.
It has been discovered that an early release facility may be provided in transactional memory designs and that, if provided, such an early release facility can allow for transaction software constructs that wait on removal (or satisfaction) of a condition that would otherwise result in transaction abort. Absent such a facility, the act of checking the condition would typically introduce a corresponding location (or locations) into the read set of the transaction, and a subsequent modification of that location (or locations) that removed (or satisfied) the condition, would result in abortion of the blocked transaction. By employing an early release facility such as described herein, a transaction may release the location (or locations) corresponding the condition, retry, and once the transient condition is removed (or satisfied), complete and commit. In this way, computation effort may be conserved while still employing a rather simple and convenient coordination facility.
The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
The use of the same reference symbols in different drawings indicates similar or identical items.
A versatile mechanism has been developed for coordinating amongst threads of a multithreaded computation that employs a transactional memory facility with early release capabilities. In general, transactional memory with early release may be implemented as part of a memory subsystem (e.g., using hardware and/or other facilities not entirely visible to application code executing on a processor), using software constructs that provide the illusion of a transactional memory (e.g., via a defined calling interface for transactional access), or using a hybrid system that combines hardware and software support.
In such cases, the transactional memory with early release may be viewed (e.g., by software that exploits it) in terms of an interface. That interface may, in general, be implemented using any of a variety of appropriate transaction encodings (e.g., using a defined calling interface, using distinct transactional instructions defined by an instruction set architecture, ISA; using extensions, modifiers, or hints supplied in conjunction with otherwise non-transactional instructions of an ISA; using portions of an addressable memory space defined, or definable, as subject to transactional access constraints; etc.). In general, appropriate transaction encodings are matters of design choice. For clarity of illustration, we have chosen to explain our techniques in the context of an illustrative computational system which employs transactional instructions defined by an instruction set architecture. However, nothing herein should be interpreted as a limitation on suitable computational systems, on suitable transactional memory interfaces or on suitable encodings, protocols or mechanisms for indicating an early release. Indeed, we describe herein software constructs suitable for use with transactional memory implementations that employ a variety of techniques for indicating early release including both an explicit release technique and a time-to-live encoding.
Similarly, many software mechanisms, concrete algorithms, data structures and concurrent shared object exploitations may exploit an early release facility to allow a transactionally-defined sequence to wait on removal (or satisfaction) of a condition that would otherwise result in transaction abort. Again, for clarity of illustration, and without limitation, we have chosen to explain our techniques in the context of an illustrative transaction that employs a bounded queue. Of course, other types of transactions employing or operating on or with other mechanisms, algorithms, data structures and concurrent shared objects are also envisioned. In general, any transaction that expends computational effort that may be wasted due to a condition that, though important to completion of the transaction, does not implicate the correctness of the computation or consistency of computational states is a candidate. A classic example is a transaction that fails (or rather would otherwise fail) due to unavailable space in an output buffer or other data structure. Accordingly, and without limitation, we explain our techniques in the context of a transaction that reads output buffer state, and upon detection of a full buffer condition, releases the location(s) read in ascertaining the full buffer condition and retries. Typically, a transaction so defined can successfully complete and commit despite the modification, e.g., by another transaction or mechanism, of output buffer state (e.g., making space available by dequeuing items or growing the buffer).
Therefore, in view of the above, and without limitation, certain illustrative exploitations of the inventive techniques are described with particular attention to an illustrative transactional memory interface and software exploitation. Such illustrative interfaces and exploitations should be viewed only as useful descriptive context, as the invention is defined solely by the claims that follow.
Transactional Memory
A multiprocessor is a computer in which multiple processors are configured to execute cooperative computations, typically communicating through a shared memory. A thread is an execution sequence (e.g., a program or distinct thread or strand of execution thereof) that executes for a relevant period on a single one of the processors.
One technique known in the art for implementing atomicity is to associate a lock with the shared data structure. A lock is typically a memory location that can be atomically modified or examined by a thread. Before a thread can access an object, it must acquire a lock by atomically changing the lock from a free state to a busy state. A thread releases a lock by atomically changing the lock from busy back to free.
Nevertheless, it is known that locks have certain disadvantages, including poor performance when the number of concurrent threads is high, and the difficulty of designing and maintaining software that uses large numbers of locks.
An alternative approach known in the art is to provide support for light-weight transactions. A transaction is a finite sequence of machine instructions, executed by a single thread, satisfying the following properties:
For clarity of description, we assume here that a thread executes only one transaction at a time, although the model can be extended to permit overlapping or logically nested transactions. Based on the description herein, persons of ordinary skill in the art will recognize suitable extensions.
Each transaction has a read set, which is the set of memory locations from which it has read, and a write set, the set of memory locations to which it has written. Two transactions A and B are said to conflict if:
One way to ensure that transactions remain linearizable is by optimistic synchronization: if a conflict between two transactions is detected at runtime, one of the two transactions is aborted and restarted. There are many variations on this approach: one could use a variety of techniques to decide which transaction to abort, or one transaction could block waiting for the other to resolve the conflict by committing. The techniques disclosed herein are independent of such considerations.
A transaction is viable if no conflicts have occurred. A transaction will commit if and only if it is viable at the time it attempts to commit.
To make our discussions concrete, we assume the processor architecture provides the following special instructions.
Various possible ways are known in the art to design a computer architecture that supports transactional memory. For purposes of exposition, we will outline our examples assuming a rather simple architecture. However, based on the description herein it will be clear to those skilled in the art that our techniques can be applied to more complex architectures as well. Furthermore, as previously noted, some embodiments in accordance with the present invention may build, in part, on software transactional memory implementations. In such embodiments, special instructions may not necessarily be supported by the processor architecture itself. Instead, functions, method or other callable sequences providing similar semantics may be employed. Nonetheless, for clarity of illustration, and without loss of generality, we illustrate using the following simple processor architecture that supports transactional memory.
Modern processors typically have one or more levels of caches, which are specialized high-speed memories that hold values recently read from or written to memory. In a conventional cache architecture that does not support transactions, each cache entry typically includes the following fields: the memory address to which the entry corresponds, the value read or written, and a status value that indicates whether the cache entry is invalid (not currently in use), shared (the same entry may be cached at other processors) or exclusive (the same entry may not be cached at other processors). If the entry is exclusive the status also indicates whether the entry is dirty, meaning that the cached value is not the same as the value in memory, and must be written back to memory before the cache entry can be reused, or clean, meaning that the cached value is the same as the value in memory, and need not be written back.
If processor P wants to write to memory location a currently cached at processor Q, then P must invalidate Q's entry for a. If that entry is dirty, Q must write that value back to location a. Once Q's entry is invalidated, its status becomes invalid.
This basic architecture can be extended to support transactions as follows. The status field for each cache entry is extended to indicate whether the entry is transactional, meaning that it has been read or written by a transaction. Each thread also has a transaction status register, which indicates whether that thread is currently executing a transaction. In practice, each processor has only one active transaction at any time, and the transaction status is in a register of the processor. The register contains active while a transaction is in progress, and becomes inactive when a transaction commits or aborts. A conflict occurs whenever a transactional cache entry is invalidated. Invalidating a transactional entry changes the transaction status register to from active to aborted. An active transaction may commit only if its status register is active. Committing a transaction causes each transactional cache entry to be marked non-transactional, with those entries written by the transaction becoming dirty, and those read and not written becoming shared. Aborting a transaction causes each transactional entry to be invalidated.
If a transaction reads or writes too many locations to fit in the cache, then the overflow items may be written to a victim cache, or the transaction may simply abort. Either way, it is desirable to minimize the number of distinct memory locations read or written by a transaction.
Illustrative Transactions
We now describe some limitations of the basic transactional memory architecture illustrated above in the context of particular transactions. Transactional operations on dynamically-sized data structures (e.g., lists, trees, etc.) present one set of challenges that we seek to address. In particular, concurrency can be severely limited by conflicts in the transactional location working sets of concurrently executing transactions that access such a data structure. Another set of challenges relates to transactional operations that perform significant computations but which can fail on a condition (e.g., buffer full) whose eventual removal or satisfaction does not necessarily undermine the validity of the prior computations. In each case, an early release facility can be employed to improve concurrency. We illustrate each in turn.
Dynamically-Sized Data Structures
Consider a sorted linked list where each list node has two fields: an integer key and a pointer to its successor, as illustrated by the code that appears below.
typedef struct node_s {
node_t *next;
int key;
} node_t;
node_t *prey; // before target node
node_t *curr; // target node
Assume, for purposes of this example, that list nodes are sorted in ascending order by key, that the first and last keys are special minimum and maximum values never searched for or inserted, and that keys are never duplicated.
It will be clear to those skilled in the art that if a key is present in the list, then a find procedure such as illustrated by the exemplary code below will locate the node containing that key, store that node's address in the curr variable, and store that node's predecessor's address in the prey variable. Moreover, the procedure will return 0 if it does not find the key, and a non-zero value otherwise.
int find(node_t *head, int searchKey) {
int currKey;
prey=head;
curr=(node_t*)t_load(&head->next);
currKey=(int)t_load(&curr->key);
while (currKey <searchKey) {
}
return currKey==searchKey;
}
Similarly, a remove procedure, such as illustrated below, executes a transaction that takes a list and a search key. If the key is present in the list, it removes the node containing that key from the list and returns that node's address. If the key is not present in the list, it returns a NULL address.
node_t *remove (node_t *head, int searchKey) {
node_t *next;
retry:
Based on the preceding code, it will be clear to those skilled in the art that concurrently executed transactions, while correct, have substantial practical limitations. The main problem is that the remove transaction's read set includes all the list nodes from the start of the list up to and including the list element holding the desired key. If the key is not present, then the read set consists of the entire list. This is troublesome for two reasons:
These outcomes are particularly troublesome because there is no logical reason two transactions deleting distinct elements should conflict, and because if the list is too large, it will be impossible to update it using a transaction, even if there are no synchronization conflicts. Later, we describe software constructs that exploit an early release facility of an extended transactional memory implementation to address the above-described design challenges.
Wait on Condition
Another limitation can be illustrated in the context of an implementation of a bounded first-in-first-out queue object. The queue can be represented (as illustrated below) by a structure with the following fields: buffer is an array of 16 integers, head is the index of the first occupied slot, if any, and size is the number of items in the queue. The isEmpty and isFull procedures respectively check whether the queue is empty or full, and the enq and deq procedures respectively insert a value at the front of the queue and remove the value at the end of the queue. Note that it is the responsibility of the caller to test whether the queue is full before calling enq, and to test whether the queue is empty before calling deq. The following code provides a concrete framework for our discussion.
#define SIZE 16
#define MASK (SIZE−1)
typedef struct queue_s {
int buffer[SIZE];
int head; // index of first occupied slot
int size; // number of occupied slots
} queue_t;
int is Empty(queue_t *queue) {
return t_load(&queue->size)==0;
}
int is Full(queue_t *queue) {
return t_load(&queue->size)==SIZE;
}
void enq(queue_t *queue, int value) {
int head, size, index;
size=(int)t_load(&queue->size);
head=(int)t_load(&queue->head);
index=(head+size) & MASK;
t_store(&queue->buffer[index], (void *)value);
t_store(&queue->size, (void *)(size+1));
}
int deq(queue_t *queue) {
int head, size, index, value;
size=(int)t_load(&queue->size);
head=(int)t_load(&queue->head);
index=head & MASK;
value=(int)t_load(&queue->buffer[index]);
t_store(&queue->head, (void *)(head+1));
t_store(&queue->size, (void *)(size−1));
return value;
}
Building on the preceding implementation of a shared queue, a simple procedure, process, is illustrated below. The simple procedure uses a transaction to dequeue an item from one queue, process it somehow, and enqueue the result on another queue. For simplicity of presentation, we assume the first queue is always non-empty, but the second queue might be full, so before pushing an item onto the second queue, the application checks whether that queue is full. If so, the application aborts and restarts the transaction.
/*
* atomically dequeue, process, and enqueue value
*/
void process(queue_t *q0, queue_t *q1) {
int value, newValue;
retry:
t_start(retry);
value=deq(q0); // assume non-empty
newValue=transform(value); // expensive transformation
if (is Full(q1)) {// is there room?
}
enq(q1, newValue); // yes, enqueue and commit
t_commit( );
}
Unfortunately, this program structure is wasteful because aborting and restarting the transaction discards all the processing work on the dequeued value. Instead, it might be more efficient for the transaction to wait for the second queue to become non-full before proceeding. The difficulty is that once the transaction has examined the second queue's size, its size field is part of the transaction's read set, and any subsequent modification to that field (caused by removing a value) will abort the blocked transaction. As before, an early release facility would allow us to address these design challenges.
Software Exploitations of Transactional Memory with Early Release
Both of the previously illustrated problems can be solved if there were some way for a transaction to release a memory location from its read set, so that subsequent modifications to that location would not cause a synchronization conflict. As previously' noted, our techniques may be applied in transactional memory environments in which transactional access is mediated at least in part by hardware (e.g., using facilities of a memory subsystem), by software (e.g., using a software transactional memory interface) or using some combination of the two. For clarity, we illustrate in the context of a transactional memory interface that includes instructions (whether distinct or coded as variants on conventional instructions) that direct operation of a hardware transactional memory implementation. Based on this description, persons of ordinary skill in the art will appreciate suitable interfaces for transactional memory interfaces defined (at least in part) by software. For breath of illustration, and without limitation, we describe two candidate interfaces: a time-to-live interface and an explicit release interface.
Candidate Interface—Time to Live
One set of potential designs for specifying early release builds on the concept of releasing a transactional location from the working set of a transaction at a somewhat predetermined future time or coincident with a future event. In some implementations in accordance with the present invention, we allow transaction code to specify a time-to-live for particular transactionally-mediated loads and/or stores. For example, in some implementations, we specify a number of events through which a transactional location that is introduced into a working set of a transaction, should remain in the working set. Specially defined load and/or store operations may be employed to define a time-to-live. Parameterized load and/or store instructions that include a time-to-live (TTL) in a field of the instruction word (or as an operand) may also be defined. Alternatively, an operative time-to-live may be specified by use of another mechanism and applied to transactional loads and/or stores. In addition, instruction extension mechanisms (including hints) may be employed. In general, such decisions are matters of design choice and, based on the description herein, selections suitable for a given design will be appreciated by persons of ordinary skill in the art.
Just as a variety of codings may be employed for specifying the initiation of a time-to-live interval, many possible mechanisms exist for aging a particular transactional location. Such mechanisms may have explicit coding in transaction code or, in some realizations, may be implicit in operation of the transaction environment. For example, the transactionally-mediated “life” of a given transactional location may be advanced by executions of a defined instruction (e.g., a release instruction). Alternatively, aging could be implicit in executions of other instructions (e.g., transactional loads or stores) or implicit is some other operation (e.g., a defined number of instruction cycles) or measure.
Clarity of description, and indeed ease of programming, is likely greatest where we specify “time-to-live” using specially coded load and/or store instructions and advance “time” explicitly through executions of release operations. Accordingly, we now describe an illustrative time-to-live style interface, using the following instructions:
The t_storen instructions are useful for “benevolent side-effects”, where a transaction wants to record metering or debugging information.
Regarding the treatment of memory locations that are accessed by multiple ones of the above instructions during a single transaction, a variety of design choices are possible. For example, a time-to-live specified by later accesses may override that specified by earlier accesses. Alternatively, a maximum of remaining time-to-live and that later specified may be applied. Other formulations are also possible and persons of ordinary skill in the art may select an appropriate treatment based on design factors particular to their implementations. For the purposes of illustrating our techniques, we have only specified the behavior of transactions in which each memory location is accessed at most once by a transaction.
Application to Dynamically-Sized Data Structures
To illustrate the use of a time-to-live style interface, let us first revisit the linked-list example. The code that follows shows a revised version of the find ( ) procedure that employs transactional load instructions (t_load2) that specify a time-to-live of two release cycles.
int find(node_t *head, int searchKey) {
int currKey;
prey=head;
curr=(node_t *)t_load2(&(head->next));
currKey=(int)t_load2(&curr->key);
while (currKey<searchKey) {
return currKey==searchKey;
}
This procedure uses t_load2 operations to read each node's contents. It ensures that at any time the transaction's read set includes both the node being examined and its predecessor. All previous nodes are released from the read set. This discipline ensures that the node being examined cannot be removed from the list by a concurrent transaction because the previous node's next field belongs to the current transaction's read set. Notice the use of t_load2 instead of t_load allows concurrent transactions to remove non-adjacent nodes without provoking synchronization conflicts.
While the illustrated code is for a singly-linked list-type data structure, extensions to release back-pointers in a doubly-linked lists (and similar data structures) are straightforward and will be appreciated by persons of ordinary skill in the art. Similarly, applications to descending (i.e., non-retracing) access of tree or tree-like data structures are also straightforward. Retracing access (if mediated using reverse, i.e., ascending, pointers) is also straightforward. In general, data structures and access methods for which traversal allows information encoded in previously traversed elements to be forgotten (i.e., eliminated from the read set of the transaction) are all suitable candidates for implementation using time-to-live style release techniques. For simplicity, we presume that all release executions advance “time” for all time-parameterized transactional loads (and perhaps stores). However, certain types of dynamically-sized data structures (e.g., skip-lists) may benefit from multiple independent release sequences that may be applied to age different types (e.g., levels) of pointers. Alternatively skip lists and other more complex data structures and/or access patterns may benefit from an explicit address formulation of release described later herein.
Application to Transaction that may Profitably Wait on a Condition
Next, we revisit the bounded queue example. Here, we alter the isFull procedure to use t_load1, and we alter the process procedure so that if it discovers the second queue is full, it releases the size field from its read set and repeatedly rereads the queue size without aborting and restarting the transaction, and without discarding the work it has performed so far.
#define SIZE 16
#define MASK (SIZE−1)
typedef struct queue_s {
int buffer[SIZE];
int head; // index of first occupied slot
int size; // number of occupied slots
} queue_t;
int is Full(queue_t *queue) {
return t_load1(&queue->size)==SIZE;
}
/*
* atomically dequeue, process, and enqueue value
*/
void process(queue_t *q0, queue_t *q1) {
int value, newValue;
retry:
Notice that the use of t_load1 (and subsequent t_release) instead of t_load allows concurrent transactions to remove one or more nodes from q1 and update size without necessarily provoking synchronization conflicts. By releasing the transactional location corresponding to queue->size from the read-set of a transaction, the process procedure allows the transaction to wait on satisfaction of the output buffer not full condition (! isFull(q1)). Since appropriate retry timing will, in general, be application-specific, no particular backoff or other timing technique is specifically shown. However, based on the description herein, persons of ordinary skill in the art may readily incorporate an appropriate backoff, delay or timing technique.
As with the previous example of early-release exploitations for transactions that access dynamically-sized data structures, exploitations of an early-release facility for transactions that may profitably wait on a condition are not limited to the full output buffer scenario illustrated. Indeed, the technique may more generally be employed to wait on satisfaction (or removal) of any condition that does not implicate the correctness of the transaction. In general, these conditions amenable to such treatment are application specific and the techniques we describe may be employed as appropriate by persons of ordinary skill in the art.
Supporting Modifications to a Cache Architecture
We now describe one possible set of modifications to the previously described cache architecture, which may be employed in support of transactional instructions such as those described above. For ease of presentation, we assume the simple cache architecture described above, although it will be appreciated by one skilled in the art that these modifications are applicable to a range of different designs.
Let l be the largest integer for which an architecture supports t_loadn. We add a time-to-live (TTL) field to each cache entry's status. Typically, each word or separately addressable location in a cache line will have an associated TTL field. This field's value ranges from 0 to l−1. A t_load or t_store call sets that entry to any other distinguished value (perhaps l) that indicates that the entry remains transactional for the lifetime of the transaction. A t_loadn or t_storen call fills the cache entry just as before, except that it sets the time-to-live field to n−1. Each time a viable transaction calls t_release, a non-zero time-to-live field for any such entry is decremented. If the time-to-live field is zero, that entry is marked as non-transactional, and treated as if it had been filled by a non-transactional instruction. For example, if the entry was filled by t_loadn, then it becomes valid, and if it was filled by t_storen, then it becomes dirty. Invalidating such an entry does not abort the current transaction. Note that the time-to-live fields of Cache entries filled by t_load or t_store instructions are not decremented by t_release calls.
For clarity, we have omitted other possible transitions, such as the transitions that occur when a value loaded for transactional reading is reloaded for transactional writing. Typically, exclusive states (resulting from store operations) would be expected to dominate. Similarly, transitions appropriate in the case of a first time-to-live parameterized transactional access followed by a second targeting the same location (or cache line), e.g., a t_load1 (&location) following a t_load2 (&location), are implementation dependent or matters of design choice. In general, persons of ordinary skill in the art will select transitions appropriate to their implementation.
Candidate Interface—Address-Specific Release
An alternative interface is to instead provide a single instruction, t_release_addr, that takes an address as an argument and removes a transactional location corresponding to that address from the current transaction's read or write set. Given such an interface, time-to-live denominated transactional load and store operations may typically be omitted and timing of release for a location previously introduced into a transactional working set by operation of a t_load or t_store instruction is coded by placement of a corresponding t_release_addr in execution sequence of the implemented transaction. For certain classes of data structures and/or algorithms, an address-specific release mechanism may prove more powerful or flexible. For example, as previously described, in data structures in which release sets may be data or execution sequence dependent and not predictable in advance, an address-specific release mechanism may facilitate exploitation of our techniques.
In general, a time-to-live interface may be more convenient for regular data structures in which significant numbers of locations may be released in correspondence with a particular step in traversal of the data structure. However, less regular dynamically-sized structures may benefit from the address-specific release. A given transactional memory implementation may support both mechanisms, if desired.
Referring back to our previous description of supporting modifications to a cache architecture, the t_release_addr instruction can be implemented simply by resetting the cache entry for that address to be non-transactional. Per-word or per-location tracking is desirable, particularly for implementations that support the t_release_addr instruction. Time-to-live tracking need not be provided unless desired.
Application to Dynamically-Sized Data Structures
To illustrate the use of an explicit-release interface, we revisit the linked-list example. The code that follows shows a revised version of the find ( )procedure that employs address specific release instructions (t_release_addr). In the ated code, loads are assumed to be transactional. However, alternative implementations may explicit code the transactional loads (e.g., using a t_load instruction, an appropriate function or the like).
int find(node_t* head, int searchKey) {
int currKey;
last=NULL;
prey=head;
curr=(node_t *)head->next;
currKey=curr->key;
while (currKey>searchKey) {
return currKey==searchKey;
}
Operation of the revised find( )procedure will be understood in the context of our prior discussion.
Application to Transaction that may Profitably Wait on a Condition
To further illustrate the use of an explicit-release interface, we revisit the bounded queue example. The code that follows shows a revised version of the process( ) procedure that employs address specific release instructions (t_release_addr). As before, loads are assumed to be transactional. However, alternative implementations may explicitly code the transactional loads (e.g., using a t_load instruction, an appropriate function or the like).
#define SIZE 16
#define MASK (SIZE−1)
typedef struct queue_s {
int buffer[SIZE];
int head; // index of first occupied slot
int size; // number of occupied slots
} queue_t;
int is Full(queue_t* queue) {
return queue->size==SIZE;
}
/*
* atomically dequeue, process, and enqueue value
*/
void process(queue_t* q0, queue_t* q1) {
int value, newValue;
retry:
Operation of the revised process( ) procedure will be understood in the context of our prior discussion.
Exploitations of the Developed Techniques
Turning to the first thread 201, two load operations (205, 206) are illustrated, which are generally suggestive of operations (possibly including a lengthy sequence of operations) that traverse dynamically-sized data structure. Note that, for purposes of this generalization, neither the particular structure of elements of the dynamically-sized data structure nor the topology of the dynamically-sized data structure itself is particularly important. The particular dynamically-sized data structure may implement a simple list or may represent a more complex and/or irregular structure. In any case, first thread 201 traverses the dynamically-sized data structure and, in the process, loads information from transactional locations thereof, including e.g., elements A and B. At some point (207, 208), using facilities described herein, transactional locations corresponding to elements A and B are released from a working set of such locations associated with the implemented transaction. Building on the various realizations described above, it will be clear that such release may be triggered by a variety of mechanisms, including expiration of a previously set time-to-live (e.g., in response to execution of a requisite number of operations such as t_release or the like) and/or responsive to a explicit location targeted release mechanism (e.g., employing an operation such as t_release_addr or the like).
In any case, at some time after the release of the transactional location (or locations) corresponding to element A, the second thread 202 executes an instruction that modifies contents of a previously released location(s) corresponding to element A. Note that absent operation of the early release mechanisms described herein, we would expect that the transaction implemented by the first thread 201 would fail. However, based on the prior release of location(s) corresponding to element A, the transaction implemented by the first thread 201 may successfully commit (at 209).
Although any number of possible transactions may benefit from these techniques, the further operations of
In any case, the first transaction implemented by first thread 301 performs some substantial computation 304 for which we would like to avoid wasted computational effort. Successful completion and committing of the first transaction depends on some condition that is a function of information stored in one or more transactional locations corresponding to element C. In some sequences and/or states of the computational system, state of element C is not (yet) compatible with completion and eventual commit of the first transaction. As previously illustrated, state corresponding to element C may be a full state of a bounded output queue (e.g., element C may encode size of the bounded queue and element D may correspond to a position in that bounded queue). However, more generally, the one or more transactional locations corresponding to element C may encode any condition (or conditions) upon which the first transaction may profitably wait and which the second transaction may satisfy.
As before, ordinarily and absent the early release facilities described herein, we would expect the transaction implemented by the first thread 301 to fail because transactional load 305 introduces a transactional location corresponding to element C into the working set (read set) of the first transaction and transactional store 306 modifies that transactional location. However, in the retry sequence illustrated, the first transaction releases (307) the transactional location corresponding to element C, thereby allowing the second transaction to update the transactional location corresponding to element C and thereby satisfy (or remove) the condition without conflict with the first transaction. As before, it will be clear that release may be triggered by a variety of mechanisms, including expiration of a previously set time-to-live (e.g., in response to execution of a requisite number of operations such as t_release or the like) and/or responsive to a explicit location targeted release mechanism (e.g., employing an operation such as t_release_addr or the like).
Although any number of possible transactions may benefit from these techniques, the further operations of
Transactional Memory Implementations
This application discloses novel extensions (including early release facilities) to transactional memory interfaces and implementations and related software constructs that exploit the extended transactional memory. These extensions support non-blocking access to data structures of unbounded size, while consuming only bounded hardware resources. These extensions also permit transactions to pause for bounded durations waiting for conditions to become true. In general, suitable transactional memory interfaces and implementations may be provided in hardware, in software or in a combination of the two. For purposes of the present invention, any of a variety of transactional memory interfaces and/or implementations may be employed.
Exemplary Hardware Transactional Memory Environments
In some exploitations, an underlying hardware transactional memory architecture may be employed in support of the early release facilities described above.
While the above-referenced applications detail several suitable hardware transactional memory environments, we summarize with reference to
Processor 101 includes one or more register file(s) 403 and one or more functional units 404, e.g., arithmetic units, load/store units, floating point units and/or other specialized functional units. In general, such functional units can be used in performing computational operations involving operands retrieved from register file(s) 403. In some realizations, load and store operations utilize respective load buffers and store buffers (not specifically shown) coupled between the functional units and the L2 cache. In some implementations, both an “active register file” and a backup “shadow register file” are provided to facilitate check pointing. In some implementations, processor 101 provides a flash copy operation that instantly copies all of the values from register file 403 into register file 404. These features can facilitate a rapid register check pointing operation, e.g., at or following start of a transaction sequence.
Processor 101 additionally includes a level one (L1) data cache 415, which stores data items that are likely to be used by processor 101. Note that lines in L1 data cache 415 include load-marking indications 416, which indicate that a corresponding data value (e.g., an associated cache line or word) has been loaded during transactional execution. These load-marking indications 416 are used to determine whether interfering memory references take place during transactional execution. Single-bit load marking may be employed in some implementations, although for time-to-live based interfaces, sufficient additional bits should be provided to support “time” encodings supported by the implementation. See the preceding description of t_loadn and t_storen encodings for examples.
Processor 101 may also include an L1 instruction cache (not shown). Suitable determinations will be understood based on the preceding general disclosure of transactional memory operation and early release. To support atomic commitment of all changes made by a transaction, such changes may be recorded in a store buffer; stores in this buffer are not released to memory system 450 until the transaction completes without encountering a conflicting access that causes it to abort.
In general, load-marking can take place at any level cache, such as L2 cache 420, or even in an independent structure. However, for performance reasons, the load-marking will typically take place at the cache level that is as close to the processor as possible, which in this case is L1 data cache 415. L2 cache 420 operates in concert with L1 data cache 415 (and a corresponding L1 instruction cache) in processor 101, and with L1 data cache 417 (and a corresponding L1 instruction cache) in processor 102. Load-marking indications 416 and 418 should be defined at a level of granularity suitable for the particular early release interface provided. Typically, per-word or per-addressable-location marking is suitable.
In addition to the load marking facilities described, store marking indications are also provided in the illustrated cache architecture. Elements (typically lines) in L2 cache 420 have associated store-marking indications 419 that indicate that a data value has been stored to the element (line) during transactional execution. Store-marking indications are used to determine whether interfering memory references take place during transactional execution. Note that, while convenient for write through L1 cache configuration illustrated, store-marking does not necessarily have to take place in L2 cache 420. Ideally, the store-marking takes place in the cache level closest to the processor where cache lines are coherent. For write-through L1 data caches, writes are automatically propagated to L2 cache 420. However, if an L1 data cache is a write-back cache, store-marking may be provided in the L1 data cache.
Exemplary Software Transactional Memory Environments
While hardware implementations may provide certain performance advantages, an underlying software transactional memory implementation may also be employed in support of the early release facilities described herein. For example, one such suitable implementation is described in commonly-owned, co-pending U.S. patent application Ser. No. 10/621,072, filed Jul. 16, 2003, now U.S. Pat. No. 7,328,316, which issued Feb. 5, 2008, entitled “Software Transactional Memory for Dynamically Sizable Shared Data Structures,” and naming Moir, Luchangco and Herlihy and inventors. U.S. Pat. No. 7,328,316 is incorporated herein by reference.
Portions of the incorporated patent application describe a release function tm_release that operates to release a block of storage previously opened for transactional access, and which may be employed to support the techniques described herein. Based on the description herein, persons of ordinary skill in the art will appreciate suitable adaptations of the early release interfaces described herein to conform with those described in U.S. patent application Ser. No. 10/621,072, now U.S. Pat. No. 7,328,316, which issued Feb. 5, 2008, or vice versa. In general, the dynamic software transactional memory support described in the above-incorporated U.S. Patent Application provides powerful way to reduce conflicts between transactions. Before a transaction commits, it may release an object that it has opened in READ mode by invoking the release ( ) method. Once an object has been released, other transactions accessing that object do not conflict with the releasing transaction over the released object.
While the invention(s) is(are) described with reference to various implementations and exploitations, it will be understood that these embodiments are illustrative and that the scope of the invention(s) is not limited to them. Terms such as always, never, all, none, etc. are used herein to describe sets of consistent states presented by a given computational system, particularly in the context of correctness proofs. Of course, persons of ordinary skill in the art will recognize that certain transitory states may and do exist in physical implementations even if not presented by the computational system. Accordingly, such terms and invariants will be understood in the context of consistent states presented by a given computational system rather than as a requirement for precisely simultaneous effect of multiple state changes. This “hiding” of internal states is commonly referred to by calling the composite operation “atomic”, and by allusion to a prohibition against any process seeing any of the internal states partially performed.
Many variations, modifications, additions, and improvements are possible. For example, while application to particular concurrent shared objects and particular implementations thereof have been described in detail herein, applications to other shared objects and other implementations will also be appreciated by persons of ordinary skill in the art. In addition, more complex shared object structures may be defined, which exploit the techniques described herein. Plural instances may be provided for components, operations or structures described herein as a single instance. Finally, boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the invention(s).
In general, structures and functionality presented as separate components in the exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the invention(s).
| Number | Name | Date | Kind |
|---|---|---|---|
| 4584640 | MacGregor et al. | Apr 1986 | A |
| 4847754 | Obermarck et al. | Jul 1989 | A |
| 5222217 | Blount et al. | Jun 1993 | A |
| 5224215 | Disbrow | Jun 1993 | A |
| 5241675 | Sheth et al. | Aug 1993 | A |
| 5319778 | Catino | Jun 1994 | A |
| 5369757 | Spiro et al. | Nov 1994 | A |
| 5428761 | Herlihy et al. | Jun 1995 | A |
| 5657474 | Taine et al. | Aug 1997 | A |
| 5701432 | Wong et al. | Dec 1997 | A |
| 5742785 | Stone et al. | Apr 1998 | A |
| 5926835 | Guidot et al. | Jul 1999 | A |
| 5937199 | Temple | Aug 1999 | A |
| 5960436 | Chang et al. | Sep 1999 | A |
| 5974438 | Neufeld | Oct 1999 | A |
| 6021480 | Pettey | Feb 2000 | A |
| 6128710 | Greenspan et al. | Oct 2000 | A |
| 6128713 | Eisler et al. | Oct 2000 | A |
| 6144965 | Oliver | Nov 2000 | A |
| 6178423 | Douceur et al. | Jan 2001 | B1 |
| 6263360 | Arnold et al. | Jul 2001 | B1 |
| 6360219 | Bretl et al. | Mar 2002 | B1 |
| 6360220 | Forin | Mar 2002 | B1 |
| 6366932 | Christenson | Apr 2002 | B1 |
| 6425048 | Kaganoi | Jul 2002 | B1 |
| 6449673 | Gupta | Sep 2002 | B1 |
| 6460124 | Kagi et al. | Oct 2002 | B1 |
| 6493741 | Emer et al. | Dec 2002 | B1 |
| 6581063 | Kirkman | Jun 2003 | B1 |
| 6651146 | Srinivas et al. | Nov 2003 | B1 |
| 6675192 | Emer et al. | Jan 2004 | B2 |
| 6681226 | Bretl et al. | Jan 2004 | B2 |
| 6697927 | Bonola | Feb 2004 | B2 |
| 6826757 | Steele et al. | Nov 2004 | B2 |
| 6862664 | Tremblay et al. | Mar 2005 | B2 |
| 6918012 | Venkitakrishnan et al. | Jul 2005 | B2 |
| 7076629 | Bonola | Jul 2006 | B2 |
| 7089374 | Tremblay et al. | Aug 2006 | B2 |
| 7206903 | Moir et al. | Apr 2007 | B1 |
| 7437623 | Larson et al. | Oct 2008 | B2 |
| 20010047361 | Martin et al. | Nov 2001 | A1 |
| 20020069326 | Richardson et al. | Jun 2002 | A1 |
| 20020087810 | Boatright et al. | Jul 2002 | A1 |
| 20030066056 | Petersen et al. | Apr 2003 | A1 |
| 20030079094 | Rajwar et al. | Apr 2003 | A1 |
| 20030126186 | Rodgers et al. | Jul 2003 | A1 |
| 20030140085 | Moir et al. | Jul 2003 | A1 |
| 20030163494 | Bender et al. | Aug 2003 | A1 |
| 20030174572 | Moir et al. | Sep 2003 | A1 |
| 20030182462 | Moir et al. | Sep 2003 | A1 |
| 20030182465 | Moir et al. | Sep 2003 | A1 |
| 20040015510 | Moir et al. | Jan 2004 | A1 |
| 20040015642 | Moir et al. | Jan 2004 | A1 |
| 20040034673 | Moir et al. | Feb 2004 | A1 |
| 20040153687 | Moir et al. | Aug 2004 | A1 |
| 20040158549 | Matena et al. | Aug 2004 | A1 |
| 20040162948 | Tremblay et al. | Aug 2004 | A1 |
| 20050131899 | Dvorkin et al. | Jun 2005 | A1 |
| 20060173885 | Moir et al. | Aug 2006 | A1 |
| 20080098181 | Moir et al. | Apr 2008 | A1 |
| Number | Date | Country |
|---|---|---|
| 0 366 585 | May 1990 | EP |
| 0 466 339 | Jan 1992 | EP |
| WO 8600434 | Jan 1986 | WO |
| WO 0153942 | Jul 2001 | WO |
| WO 0153943 | Jul 2001 | WO |
| WO 0180015 | Oct 2001 | WO |
| WO 03060715 | Jul 2003 | WO |
