Multiversion Conflict Notion for Transactional Memory Systems*

In recent years, Software Transactional Memory systems (STMs) have garnered significant interest\ud as an elegant alternative for addressing concurrency issues in memory. STM systems take optimistic\ud approach. Multiple transactions are allowed to execute concurrently. On completion, each\ud transaction is validated and if any inconsistency is observed it is aborted. Otherwise it is allowed to\ud commit.\ud In databases a class of histories called as conflict-serializability (CSR) based on the notion of\ud conflicts have been identified, whose membership can be efficiently verified. As a result, CSR is the\ud commonly used correctness criterion in databases In fact all known single-version schedulers known\ud for databases are a subset of CSR. Similarly, using the notion of conflicts, a correctness criterion,\ud conflict-opacity (co-opacity) which is a sub-class of can be designed whose membership can be\ud verified in polynomial time. Using the verification mechanism, an efficient STM implementation\ud can be designed that is permissive w.r.t co-opacity. Further, many STM implementations have been\ud developed that using the notion of conflicts.\ud By storing multiple versions for each transaction object, multi-version STMs provide more concurrency\ud than single-version STMs. But the main drawback of co-opacity is that it does not admit\ud histories that are uses multiple versions. This has motivated us to develop a new conflict notions for\ud multi-version STMs. In this paper, we present a new conflict notion multi-version conflict. Using\ud this conflict notion, we identify a new subclass of opacity, mvc-opacity that admits multi-versioned\ud histories and whose membership can be verified in polynomial time. We show that co-opacity is a\ud proper subset of this class.\ud An important requirement that arises while building a multi-version STM system is to decide\ud “on the spot” or schedule online among the various versions available, which version should a transaction\ud read from? Unfortunately this notion of online scheduling can sometimes lead to unnecessary\ud aborts of transactions if not done carefully. To capture the notion of online scheduling which avoid\ud unnecessary aborts in STMs, we have identified a new concept ols-permissiveness and is defined\ud w.r.t a correctness-criterion, similar to permissiveness. We show that it is impossible for a STM system\ud that is permissive w.r.t opacity to such avoid un-necessary aborts i.e. satisfy ols-permissiveness\ud w.r.t opacity. We show this result is true for mvc-opacity as well