Citation Context

...s. However, their solution requires acquiring a read-lock for every location being read. Our new fully pessimistic STM design is an encounter-time variation of our earlier commit-time pessimistic STM =-=[3]-=-. Our algorithm executes write transactions sequentially in a manner similar to [5], yet allows concurrent wait-free read-only transactions without using read-locks or multiple versions as in [10, 7]....

Citation Context

... providing multiple versions of transaction view for reads [1, 12]. In other cases, irrevocable operations are just forbidden in transactions (e.g., in Haskell). A different approach, as suggested by =-=[10]-=- and our earlier work [17, 18], is to use fully-pessimistic concurrency control. This involves transactions waiting until they have permission to access shared objects. In effect, conflicting operatio...

Citation Context

...ect update mode (WT) or with buffered updates and encounter time locking (ETL). Pessimistic transactions, like the master in FASTLANE, have been proposed in different flavors. A fully pessimistic STM =-=[14]-=- executes every transaction once and never aborts, enabling the execution of irrevocable operations and simpler debugging at the cost of limiting concurrent updates. ROBUSTM [27] starts to execute tra...

Citation Context

...iding multiple versions of transaction view for reads [1,18]. In other cases, irrevocable operations are simply forbidden in transactions (e.g., in Haskell [8]). A different approach, as suggested by =-=[14]-=- and our earlier work [27,28], is to use fully-pessimistic concurrency control. This involves transactions waiting until they have permission to access shared objects. In effect, potentially conflicti...

Citation Context

...however, a system should prevent unexpected results from occurring in presence of race conditions. Furthermore, concurrency control should ideally be implicit and never be delegated to the programmer =-=[2, 12]-=-. These are the reasons for which strong isolation is desirable. Under strong isolation, the aforementioned scenarios, where non-transactional operations violate transaction isolation, would not be al...

Citation Context

...more elaborated discussion, as well as a correctness proof for SemanticTM, will be provided in future versions of the paper. TM algorithms that never abort transactions has been recently presented in =-=[1, 14]-=-. These algorithms use ideas from [21] where a TM algorithm supporting one irrevocable transaction at each point in time is presented. In the algorithms in [1, 14], read-only transactions are wait-fre...

Citation Context

...however, a system should prevent unexpected results from occurring in presence of race conditions. Furthermore, concurrency control should ideally be implicit and never be delegated to the programmer =-=[2, 12]-=-. These are the reasons for which strong isolation is desirable. Under strong isolation, the aforementioned scenarios, where non-transactional operations violate transaction isolation, would not be al...

Citation Context

...iding multiple versions of transaction view for reads [1,18]. In other cases, irrevocable operations are simply forbidden in transactions (e.g., in Haskell [8]). A different approach, as suggested by =-=[14]-=- and our earlier work [27,28], is to use fully-pessimistic concurrency control. This involves transactions waiting until they have permission to access shared objects. In effect, potentially conflicti...

Citation Context

...about atomicity. Implementations typically achieve this by dynamically detecting conflicts between concurrent threads. This can be done tracking memory operations in hardware [15, 17, 16] or software =-=[14, 6, 8, 25, 4]-=-. Meanwhile, an alternate approach exploits abstract-level notions of conflict over linearizable data-structure operations such as commutativity [11, 28, 21, 20]. Both levels of abstraction also chose...