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.

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: Various technologies and techniques are disclosed for implementing retrying transactions in a transactional memory system. The system allows a transaction to execute a retry operation. The system registers for waits on every read in a read set of the retrying transaction. The retrying transaction waits for notification that something in the read set has changed. A transaction knows if notification is required in one of two ways. If the transactional memory word contained a waiters bit during write lock acquisition, then during release the transactional memory word is looked up in an object waiters map, and waiting transactions are signaled. If a writing transaction finds a global count of waiting transactions to be greater than zero after releasing write locks, a transaction waiters map is used to determine which waiting transactions need to be signaled. In each case, the write lock is released using a normal store operation.

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 handling exceptions in sequential statements that are executed in parallel. A transactional memory system is provided with a contention manager. The contention manager is responsible for managing exceptions that occur within statements that were designed to be executed in an original sequential order, and that were transformed into ordered transactions for speculative execution in parallel. The contention manager ensures that any exceptions that are thrown from one or more speculatively executed blocks while the statements are being executed speculatively in parallel are handled in the original sequential order.

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 applying ordering to transactions in a software transactional memory system. A software transactional memory system is provided with a feature to allow a pre-determined commit order to be specified for a plurality of transactions. The pre-determined commit order is used at runtime to aid in determining an order in which to commit the transactions in the software transactional memory system. A contention management process is invoked when a conflict occurs between a first transaction and a second transaction. The pre-determined commit order is used in the contention management process to aid in determining whether the first transaction or the second transaction should win the conflict and be allowed to proceed.

Abstract: Various technologies and techniques are disclosed that improve implementation of concurrency control modes in a transactional memory system. A transactional memory word is provided for each piece of data. The transactional memory word includes a version number, a reader indicator, and an exclusive writer indicator. The transactional memory word is analyzed to determine if the particular concurrency control mode is proper. Using the transactional memory word to help with concurrency control allows multiple combinations of operations to be performed against the same memory location simultaneously and/or from different transactions. For example, a pessimistic read operation and an optimistic read operation can be performed against the same memory location.

Abstract: Apparatus (1) for watering plants in a hanging basket or window box at a relatively high level comprises a container (10) for water pivotally carried at a distal end (6) of a shaft (4). A cap (27) secured to a discharge outlet (12) is provided with a plurality of discharge bores (30) extending therethrough for facilitating discharge of water in a sprinkle type spray from the container (10). A pivot mounting (14) having a first pivot pin (18) pivotally couples the container (10) to a shaft (4) so that the container (10) is pivotal from a first orientation illustrated in FIG. 7 inhibiting discharge of water from the container (10) to a second orientation illustrated in FIG. 8 for discharging water through the discharge outlet (12). The pivot mounting (14) is located on the container (10) relative to the centre of gravity (32) thereof so that as the shaft (4) is rotated through 180° from the orientation illustrated in FIG. 7 to that illustrated in FIG.

Abstract: Various technologies and techniques are disclosed for providing a software transactional memory system that supports allocation and use of finalizable objects inside transactions. By supporting such finalizable object usage inside a software transactional memory system, correct behavior is maintained when a garbage collector must determine when a particular one or more of the objects are eligible for finalization. A to-be-finalized set is provided for a transaction. An object is placed into the to-be-finalized set for the transaction whenever a finalizable object is allocated within the transaction. A finalize indicator is set for each object in the to-be-finalized set at an appropriate time to indicate that the objects are eligible for finalization. For example, if the transaction is ready to commit and the transaction is an open transaction, then the to-be-finalized set is traversed and a finalize indicator is set for each object to indicate they are eligible for finalization.

Abstract: The subject disclosure pertains to systems and methods for supporting null capabilities for general purpose programming languages. Low level, runtime support for a nullable type is provided to ensure consistency and coherency. An execution component restricts support of the nullable type to programming language types that lack a null capability. The execution component may also provide support for conversion between the nullable type and a reference type.

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 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: Methods and compounds effective in ameliorating conditions characterized by unwanted calcium channel activity, particularly unwanted N-type and/or T-type calcium channel activity are disclosed. Specifically, a series of compounds containing both an amino acid functionality and multiple aromatic rings are disclosed of the general formula (1) where X is benzhydryl, or an aromatic or heteroaromatic ring.

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 implementing retrying transactions in a transactional memory system. The system allows a transaction to execute a retry operation. The system registers for waits on every read in a read set of the retrying transaction. The retrying transaction waits for notification that something in the read set has changed. A transaction knows if notification is required in one of two ways. If the transactional memory word contained a waiters bit during write lock acquisition, then during release the transactional memory word is looked up in an object waiters map, and waiting transactions are signaled. If a writing transaction finds a global count of waiting transactions to be greater than zero after releasing write locks, a transaction waiters map is used to determine which waiting transactions need to be signaled. In each case, the write lock is released using a normal store operation.