Abstract: Various technologies and techniques are disclosed that provide software transactional protection of managed pointers. A software transactional memory system interacts with and/or includes a compiler. At compile time, the compiler determines that there are one or more reference arguments in one or more code segments being compiled whose source cannot be recovered. The compiler executes a procedure to select one or more appropriate techniques or combinations thereof for communicating the sources of the referenced variables to the called code segments to ensure the referenced variables can be recovered when needed. Some examples of these techniques include a fattened by-ref technique, a static fattening technique, a dynamic ByRefInfo type technique, and others. One or more combinations of these techniques can be used as appropriate.

Abstract: Various technologies and techniques are disclosed for providing type stability techniques to enhance contention management. A reference counting mechanism is provided that enables transactions to safely examine states of other transactions. Contention management is facilitated using the reference counting mechanism. When a conflict is detected between two transactions, owning transaction information is obtained. A reference count of the owning transaction is incremented. The system ensures that the correct transaction was incremented. If the owning transaction is still a conflicting transaction, then a contention management decision is made to determine proper resolution. When the decision is made, the reference count on the owning transaction is decremented by the conflicting transaction. When each transaction completes, the reference counts it holds to itself is decremented. Data structures cannot be deallocated until their reference count is zero.

Abstract: Various technologies and techniques are disclosed for transforming a sequential loop into a parallel loop for use with a transactional memory system. Open ended and/or closed ended sequential loops can be transformed to parallel loops. For example, a section of code containing an original sequential loop is analyzed to determine a fixed number of iterations for the original sequential loop. The original sequential loop is transformed into a parallel loop that can generate transactions in an amount up to the fixed number of iterations. As another example, an open ended sequential loop can be transformed into a parallel loop that generates a separate transaction containing a respective work item for each iteration of a speculation pipeline. The parallel loop is then executed using the transactional memory system, with at least some of the separate transactions being executed on different threads.

Abstract: Various technologies and techniques are disclosed for providing concurrent exception handling. When one or more exceptions are received from concurrent workers, one or more exception handler functions are supplied. For each respective exception in the exception results, determine if the respective exception is one of a kind of exceptions handled by the one or more exception handler functions. If the respective exception is one of a kind handled by the exception handler functions, then run a particular handler of the exception handler functions and mark the respective exception as handled. Any unhandled exceptions are then processed appropriately. In one implementation, a collection of input data is processed to produce a collection of output results, with the exceptions being interleaved with other output results. In another implementation, a particular exception is selected that represents the multiple exceptions. The selected one particular exception is then thrown.

Abstract: Various technologies and techniques are disclosed for supporting parallel nested transactions in a transactional memory system. Releasing a duplicate write lock for rollback is supported. During rollback processing of a parallel nested transaction, a write log entry is encountered that represents a write lock. If the write lock is a duplicate, a global lock is used to synchronize access to a global versioned write lock map. Optimistic read validation is supported. During validation, if a versioned write lock indicates a sibling conflict, consult information to determine if a parallel nested transaction should be doomed. Write lock acquisition is supported. Upon attempting to acquire a write lock for a parallel nested transaction, a transactional memory word is analyzed to determine if the write lock can be obtained. If the transactional memory word indicates a versioned write lock, retrieve a write log entry pointer from a global versioned write lock map.

Abstract: Transactional memory compatibility type attributes are associated with intermediate language code to specify, for example, that intermediate language code must be run within a transaction, or must not be run within a transaction, or may be run within a transaction. Attributes are automatically produced while generating intermediate language code from annotated source code. Default rules also generate attributes. Tools use attributes to statically or dynamically check for incompatibility between intermediate language code and a transactional memory implementation.

Abstract: Various technologies and techniques are disclosed for handling data parallel operations. Data parallel operations are composed together to create a more complex data parallel operation. A fusion plan process is performed on a particular complex operation dynamically at runtime. As part of the fusion plan process, an analysis is performed of a structure of the complex operation and input data. One particular algorithm that best preserves parallelism is chosen from multiple algorithms. The structure of the complex operation is revised based on the particular algorithm chosen. A nested complex operation can also be fused, by inlining its contents into an outer complex operation so that parallelism is preserved across nested operation boundaries.

Abstract: Various technologies and techniques are disclosed for providing concurrent exception handling. Exceptions that occur in concurrent workers are caught. The caught exceptions are then forwarded from the concurrent workers to a coordination worker. The caught exceptions are finally aggregated into an aggregation structure, such as an aggregate exception object. This aggregation structure is rethrown and the individual caught exceptions may then be handled at a proper time.

Abstract: Various technologies and techniques are disclosed for preserving input element ordering in data parallel operations. This ordering may be based on element ordinal position in the input or a programmer-specified key-selection routine that generates sortable keys for each input element. Complex data parallel operations are re-written to contain individual data parallel operations that introduce partitioning and merging. Each partition is then processed independently in parallel. The system ensures that downstream operations remember ordering information established by certain other operations, using techniques that vary depending upon which categories the consumer operations are in. Data is merged back into one output stream using a final merge process that is aware of the ordering established among data elements.

Abstract: Various technologies and techniques are disclosed for providing type stability techniques to enhance contention management. A reference counting mechanism is provided that enables transactions to safely examine states of other transactions. Contention management is facilitated using the reference counting mechanism. When a conflict is detected between two transactions, owning transaction information is obtained. A reference count of the owning transaction is incremented. The system ensures that the correct transaction was incremented. If the owning transaction is still a conflicting transaction, then a contention management decision is made to determine proper resolution. When the decision is made, the reference count on the owning transaction is decremented by the conflicting transaction. When each transaction completes, the reference counts it holds to itself is decremented. Data structures cannot be deallocated until their reference count is zero.

Abstract: Various technologies and techniques are disclosed for transforming a sequential loop into a parallel loop for use with a transactional memory system. Open ended and/or closed ended sequential loops can be transformed to parallel loops. For example, a section of code containing an original sequential loop is analyzed to determine a fixed number of iterations for the original sequential loop. The original sequential loop is transformed into a parallel loop that can generate transactions in an amount up to the fixed number of iterations. As another example, an open ended sequential loop can be transformed into a parallel loop that generates a separate transaction containing a respective work item for each iteration of a speculation pipeline. The parallel loop is then executed using the transactional memory system, with at least some of the separate transactions being executed on different threads.

Abstract: Various technologies and techniques are disclosed for transforming a sequential loop into a parallel loop for use with a transactional memory system. Open ended and/or closed ended sequential loops can be transformed to parallel loops. For example, a section of code containing an original sequential loop is analyzed to determine a fixed number of iterations for the original sequential loop. The original sequential loop is transformed into a parallel loop that can generate transactions in an amount up to the fixed number of iterations. As another example, an open ended sequential loop can be transformed into a parallel loop that generates a separate transaction containing a respective work item for each iteration of a speculation pipeline. The parallel loop is then executed using the transactional memory system, with at least some of the separate transactions being executed on different threads.

Abstract: Various technologies and techniques are disclosed for transforming a sequential loop into a parallel loop for use with a transactional memory system. A transactional memory system is provided. A first section of code containing an original sequential loop is transformed into a second section of code containing a parallel loop that uses transactions to preserve an original input to output mapping. For example, the original sequential loop can be transformed into a parallel loop by taking each iteration of the original sequential loop and generating a separate transaction that follows a pre-determined commit order process. At least some of the separate transactions are executed in different threads. When an unhandled exception is detected that occurs in a particular transaction while the parallel loop is executing, state modifications made by the particular transaction and predecessor transactions are committed, and state modifications made by successor transactions are discarded.

Abstract: Various technologies and techniques are disclosed for providing type stability techniques to enhance contention management. A reference counting mechanism is provided that enables transactions to safely examine states of other transactions. Contention management is facilitated using the reference counting mechanism. When a conflict is detected between two transactions, owning transaction information is obtained. A reference count of the owning transaction is incremented. The system ensures that the correct transaction was incremented. If the owning transaction is still a conflicting transaction, then a contention management decision is made to determine proper resolution. When the decision is made, the reference count on the owning transaction is decremented by the conflicting transaction. When each transaction completes, the reference counts it holds to itself is decremented. Data structures cannot be deallocated until their reference count is zero.

Abstract: Various technologies and techniques are disclosed for supporting parallel nested transactions in a transactional memory system. For example, pessimistic reads are supported. A pessimistic duplication detection data structure is created for a parallel nested transaction. An entry is made into the data structure for each pessimistic read in the parallel nested transaction. When committing the parallel nested transaction, new pessimistic read locks are passed to an immediate parent, and an entry is made into a separate pessimistic duplication detection data structure of the immediate parent with synchronization between sibling transactions. The pessimistic duplication detection data structures can also be used for upgrades from pessimistic reads to write locks. Retry operations are supported with parallel nested transactions. Write abort compensation maps can be used with parallel nested transactions to detect and handle falsely doomed parent transactions.

Abstract: Various technologies and techniques are disclosed for supporting parallel nested transactions in a transactional memory system. Multiple closed nested transactions are created for a single parent transaction, and the closed nested transactions are executed concurrently as parallel nested transactions. Various techniques are used to ensure effects of the parallel nested transactions are hidden from other transactions outside the parent transaction until the parent transaction commits. For example, versioned write locks are used with parallel nested transactions. When a transactional memory word changes from a write lock to a versioned write lock, an entry is made in a global versioned write lock map to store a pointer to a write log entry that the versioned write lock replaced. When the versioned write lock is encountered during transaction processing, the global versioned write lock map is consulted to translate the versioned write lock to the pointer to the write log entry.

Abstract: Various technologies and techniques are disclosed for providing concurrent exception handling. When one or more exceptions are received from concurrent workers, one or more exception handler functions are supplied. For each respective exception in the exception results, determine if the respective exception is one of a kind of exceptions handled by the one or more exception handler functions. If the respective exception is one of a kind handled by the exception handler functions, then run a particular handler of the exception handler functions and mark the respective exception as handled. Any unhandled exceptions are then processed appropriately. In one implementation, a collection of input data is processed to produce a collection of output results, with the exceptions being interleaved with other output results. In another implementation, a particular exception is selected that represents the multiple exceptions. The selected one particular exception is then thrown.

Abstract: Various technologies and techniques are disclosed that support buffered writes and enforced serialization order in a software transactional memory system. A buffered write process is provided that performs writes to shadow copies of objects and writes content back to the objects after validating a respective transaction during commit. When a write lock is first obtained for a particular transaction, a shadow copy is made of a particular object. Writes are performed to and reads from the shadow copy. After validating the particular transaction during commit, content is written from the shadow copy to the particular object. A transaction ordering process is provided that ensures that an order in which the transactions are committed matches an abstract serialization order of the transactions. Transactions are not allowed to commit until their ticket number matches a global number that tracks the next transaction that should commit.

Abstract: Various technologies and techniques are disclosed for detecting falsely doomed parent transactions of nested children in transactional memory systems. When rolling back nested transactions, a release count is tracked each time that a write lock is released due to rollback for a given nested transaction. For example, a write abort compensation map can be used to track the release count for each nested transaction. The number of times the nested transactions releases a write lock is recorded in their respective write abort compensation map. The release counts can be used during a validation of a parent transaction to determine if a failed optimistic read is really valid. If an aggregated release count for the nested children transactions accounts for the difference in version numbers exactly, then the optimistic read is valid.

Abstract: Various technologies and techniques facilitate stack read and write operations in a software transactional memory system. If the compiler determines that an address for a variable in a code segment is a stack location, the stack location is live on entry, and the address of the variable has not been taken and passed to another thread, the code is changed to ensure failure atomicity. One example includes modifying the code so a shadow copy is saved for local variables that are live on entry. If the same prior criteria are true except the stack location is not live on entry, the code is optimized by ensuring code for logging and software transactional memory operations are not included. If the compiler does not know the address is the stack location or that the address is not passed to another thread, the code is changed to ensure failure and concurrency atomicity.