Last-use Opacity: A Strong Safety Property for Transactional Memory with Prerelease Support (Abstract)
[ 1 ] Instytut Informatyki, Wydział Informatyki, Politechnika Poznańska | [ 2 ] Instytut Informatyki, Wydział Informatyki i Telekomunikacji, Politechnika Poznańska | [ P ] pracownik
2024
abstrakt
angielski
EN Transaction Memory (TM) is a concurrency control abstraction that allows the programmer to specify blocks of code to be executed atomically as transactions. However, since transactional code can contain just about any operation attention must be paid to the state of shared variables at any given time. E.g., contrary to a database transaction, if a TM transaction reads a stale value it may execute dangerous operations, like attempt to divide by zero, access an illegal memory address, or enter an infinite loop. Thus serializability [10] is insufficient, and stronger safety properties are required in TM, which regulate what values can be read, even by transactions that abort. Hence, a number of TM safety properties were developed, including opacity [6], and TMS1 and TMS2 [3]. However, such strong properties preclude using prerelease as a technique for parallelizing TM, because they virtually forbid reading from live transactions. Moreover, the newest applications of TM in parallelising smart contracts do not require opacity, since the system is isolated from the damaging effects of inconsistent views at the level of virtual machines (see also sandboxing [2]). On the other hand, properties that do allow prerelease are either not strong enough to prevent any of the problems mentioned above (e.g., recoverability [7]), or add additional conditions on transactions that prerelease variables that limit their applicability (e.g., elastic opacity [7], live opacity [4], virtual world consistency [8]). In [14], we proposed last-use opacity—a new TM safety property meant to be a compromise between strong properties like opacity and minimal ones like serializability. The property eliminates all but a small class of benign inconsistent views and poses no stringent conditions on transactions.
26.07.2024
33 - 35