Abstract: A set of application programming interfaces (“APIs”) is provided that enables an application to perform operations on multiple system resources as a single logical unit of work through a transaction. The application can then commit or roll back the entire group of changes as a single unit in a coordinated manner. The APIs expose functions and methods that take a reference to a transaction context, such as a handle, name, or pointer, as one of their parameters so that the application can manipulate the resource as a transacted operation. The transaction is bound to all created handles so that all operations on the resource using those handles are also transacted. In an illustrative example, the set of APIs are transacted name-based WIN32 APIs that take a transaction handle. The transacted APIs expose transacted operations to the application for durable system resources in the OS kernel, including the NTFS file system (New Technology File System) and registry.

Abstract: A software transactional memory (STM) system allows the composition of traditional lock based synchronization with transactions in STM code. The STM system acquires each traditional lock the first time that a corresponding traditional lock acquire is encountered inside a transaction and defers all traditional lock releases until a top level transaction in a transaction nest commits or aborts. The STM system maintains state information associated with traditional lock operations in transactions and uses the state information to eliminate deferred traditional lock operations that are redundant. The STM system integrates with systems that implement garbage collection.

Abstract: A security model is provided in a transactional logging infrastructure that is arranged as a protected subsystem built on an underlying secure file system. Files in the underlying file system used by virtual log streams are protected from direct user writes, and are written-to only through the protected subsystem that is brokered by a machine-wide principal so that virtual log files sharing the same multiplexed physical log are kept secure from each other. Log file handles and user- and kernel-mode objects are exposed to log clients through interfaces using consistent security semantics for both dedicated and virtual logs. Log clients are agnostic of the underlying secure file system and can only manipulate file system containers—abstract objects that implement the physical log and used to virtualize the file system by normalizing input/output operations—by using the interfaces brokered by the principal in the protected subsystem.

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: A transactional memory processing system provides for the integration of transactional memory concepts at the compiler-level into a higher-level traditional transaction processing system. Atomic blocks at the compiler-level can be specified as atomic block transactions and include the features of atomicity and isolation. Actions within this atomic block transaction include the enlistment of resource managers from a repository. The repository can now include a pre-programmed memory resource manager to manage the transactional memory. As in traditional transactions, a commit protocol can be used to determine if the actions are valid and can be exposed outside of the transaction. Unlike traditional transactions, however, the transaction is not necessarily doomed if all of the actions are not validated. Rather, memory conflicts can cause a rollback and re-execution of the atomic block transaction, which can be repeated as long as necessary, until the memory resource manger votes to commit.

Abstract: A software transactional memory (STM) system allows the composition of traditional lock based synchronization with transactions in STM code. The STM system acquires each traditional lock the first time that a corresponding traditional lock acquire is encountered inside a transaction and defers all traditional lock releases until a top level transaction in a transaction nest commits or aborts. The STM system maintains state information associated with traditional lock operations in transactions and uses the state information to eliminate deferred traditional lock operations that are redundant. The STM system integrates with systems that implement garbage collection.

Abstract: A transactional logging service is provided to user-mode and kernel-mode log clients by utilizing a marshalling area to buffer a set of log records that a log client assembles into a log stream. Disk I/O (input/output) functionality is then separately brokered using a kernel-mode address space for a single dedicated physical log, or virtual logs multiplexed to a single log, which is written to stable storage that contains log records from across all of the log streams. Physical log writes are handled by a shared log flush queue and physical log reads are provided by a file system cache that underlies the service. A multi-level cache hierarchy is utilized when a log client needs to access a log record. A series of caches are queried in order of increasing latency until the targeted log record is located. The target log record is only read from disk in the event that it missed at each cache in the hierarchy.

Abstract: A processing system includes a transactional memory, first and second resource managers, and a transaction manager for a concurrent program having a thread including an atomic transaction having a side-effecting action. The first resource manager is configured to enlist in the atomic transaction and manage a resource related to the side effecting action. The second resource manager is configured to enlist in the atomic transaction and manage the transaction memory. The transaction manager is coupled to the first and second resource managers and manager is configured to receive a vote from the first and second resource managers as to whether to commit the transaction. The side-effecting action is postponed until after the transaction commits or applied along with a compensating action to the side-effecting action.

Abstract: A software transactional memory system is provided that provides privatization safety. The system identifies situations where the completion of a transaction may be expedited because a privatization artifact will not occur. The system determines whether a privatization artifact may occur using a read and write set intersection test, transactional variables, pessimistic locks, or declared privatizing transactions. If a privatization artifact will not occur for a transaction, then the system may allow the transaction to complete prior to one or more earlier transactions.

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: A processing system includes a transactional memory, first and second resource managers, and a transaction manager for a concurrent program having a thread including an atomic transaction having a side-effecting action. The first resource manager is configured to enlist in the atomic transaction and manage a resource related to the side effecting action. The second resource manager is configured to enlist in the atomic transaction and manage the transaction memory. The transaction manager is coupled to the first and second resource managers and manager is configured to receive a vote from the first and second resource managers as to whether to commit the transaction. The side-effecting action is postponed until after the transaction commits or applied along with a compensating action to the side-effecting action.

Abstract: A transactional memory processing system provides for the integration of transactional memory concepts at the compiler-level into a higher-level traditional transaction processing system. Atomic blocks at the compiler-level can be specified as atomic block transactions and include the features of atomicity and isolation. Actions within this atomic block transaction include the enlistment of resource managers from a repository. The repository can now include a pre-programmed memory resource manager to manage the transactional memory. As in traditional transactions, a commit protocol can be used to determine if the actions are valid and can be exposed outside of the transaction. Unlike traditional transactions, however, the transaction is not necessarily doomed if all of the actions are not validated. Rather, memory conflicts can cause a rollback and re-execution of the atomic block transaction, which can be repeated as long as necessary, until the memory resource manger votes to commit.

Abstract: A set of application programming interfaces (“APIs”) is provided that enables an application to perform operations on multiple system resources as a single logical unit of work through a transaction. The application can then commit or roll back the entire group of changes as a single unit in a coordinated manner. The APIs expose functions and methods that take a reference to a transaction context, such as a handle, name, or pointer, as one of their parameters so that the application can manipulate the resource as a transacted operation. The transaction is bound to all created handles so that all operations on the resource using those handles are also transacted. In an illustrative example, the set of APIs are transacted name-based WIN32 APIs that take a transaction handle. The transacted APIs expose transacted operations to the application for durable system resources in the OS kernel, including the NTFS file system (New Technology File System) and registry.

Abstract: A security model is provided in a transactional logging infrastructure that is arranged as a protected subsystem built on an underlying secure file system. Files in the underlying file system used by virtual log streams are protected from direct user writes, and are written-to only through the protected subsystem that is brokered by a machine-wide principal so that virtual log files sharing the same multiplexed physical log are kept secure from each other. Log file handles and user- and kernel-mode objects are exposed to log clients through interfaces using consistent security semantics for both dedicated and virtual logs. Log clients are agnostic of the underlying secure file system and can only manipulate file system containers—abstract objects that implement the physical log and used to virtualize the file system by normalizing input/output operations—by using the interfaces brokered by the principal in the protected subsystem.

Abstract: A transactional logging service is provided to user-mode and kernel-mode log clients by utilizing a marshalling area to buffer a set of log records that a log client assembles into a log stream. Disk I/O (input/output) functionality is then separately brokered using a kernel-mode address space for a single dedicated physical log, or virtual logs multiplexed to a single log, which is written to stable storage that contains log records from across all of the log streams. Physical log writes are handled by a shared log flush queue and physical log reads are provided by a file system cache that underlies the service. A multi-level cache hierarchy is utilized when a log client needs to access a log record. A series of caches are queried in order of increasing latency until the targeted log record is located. The target log record is only read from disk in the event that it missed at each cache in the hierarchy.

Abstract: Minimizing transaction managers. A method that may be practiced in a commit tree topology including a plurality of transaction managers to manage transactions. The transactions include a set of operations that are all performed if a transaction is completed or all aborted if a transaction is not completed. The transaction managers store transaction result information to allow recovery of a transaction in case of system failure. The method includes acts for minimizing storage overhead by minimizing the number of transaction managers used to coordinate transactions. The method includes identifying a set of transaction managers. A first transaction manager is selected from among the set of transaction managers. A second transaction manager is identified from among the set of transaction managers that is always available when the first transaction manager is available. Messages are redirected from a subordinate associated with the first transaction manager to the second transaction manager.

Abstract: Aspects of the subject matter described herein relate to antivirus protection and transactions. In aspects, a filter detects that a file is participating in a transaction and then may cause the file to be scanned together with any changes that have made to the file during the transaction. After a file is scanned, a cache entry may be updated to indicate that the file is clean. The cache entry may be used subsequently for like-type states. For example, if the file was scanned inside a transaction, the cache entry may be used later in the transaction. If the file was scanned outside a transaction, the cache entry may be used later for requests pertaining to files not in a transaction. Cache entries may be discarded when they are invalid or no longer useful.

Abstract: Aspects of the subject matter described herein relate to file system filters and transactions. In aspects, a filter may enlist to receive notification of events associated with a transaction. Afterwards, the filter may receive notification of a transaction event for which it has enlisted. In response to receiving notification of the transaction the filter may perform an action as appropriate. Aspects of the subject matter described herein may be applied to stacked and managed filters.

Abstract: Aspects of the subject matter described herein relate to transactions. In aspects, a consistency requester such as a shadow copy service requests to have a consistent view of a set of resources. In response, transactions that are in a problematic state are allowed to exit the problematic state while new and existing transactions that are not in the problematic state are allowed to perform any work except work that takes them into the problematic state. After no transactions are in the problematic state, a consistent view of the set of resources is available. This view may be used by the consistency requester as desired. Afterwards, the consistency requester may indicate that a consistent view is no longer needed. Transactions are then allowed to enter the problematic state. Transactions may also be allowed to enter the problematic state if a timeout elapses.