# US 2014/0156953 A1 · Unified Optimistic and Pessimistic Concurrency Control for a Software Transactional Memory (STM) System > Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt - Number: US 2014/0156953 A1 - Document ID: US20140156953A1 - Status: Published application - Kind: A1 - Application number: 14/028,018 - Filed: 2013-09-16 - Published: 2014-06-05 - Earliest claimed: 2008-12-17 - Assignees: Intel Corporation - Inventors: Ali-Reza Adl-Tabatabai; Moshe Bach; Sion Berkowits; James Henry Cownie; Yang Ni; Jeffrey V. Olivier; Bratin Saha; Ady Tal; Adam Welc - Web page: https://patentgrep.com/patent/US20140156953A1 ## CPC - G06F 9/467: {Transactional memory (G06F9/528 takes precedence)} - G06F 9/528: {by using speculative mechanisms} - G06F 16/2315: {Optimistic concurrency control} - G06F 16/2322: {using timestamps} - G06F 16/2329: {using versioning} - G06F 16/2336: {Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps} - G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N) ## Abstract A method and apparatus for unified concurrency control in a Software Transactional Memory (STM) is herein described. A transaction record associated with a memory address referenced by a transactional memory access operation includes optimistic and pessimistic concurrency control fields. Access barriers and other transactional operations/functions are utilized to maintain both fields of the transaction record, appropriately. Consequently, concurrent execution of optimistic and pessimistic transactions is enabled. ## Claims ### Claim 1 A system comprising: machine readable medium to hold program code, when executed, to determine dynamically if a transaction is to be executed pessimistically; modify a pointer of an indirect call to an optimistic read barrier for a transactional load operation within the transaction to call to reference a pessimistic read barrier in response to determining dynamically the transaction is to be executed pessimistically; and a processor associated with the machine readable medium to execute the program code. ### Claim 2 (depends on 1) The system of claim 1, wherein to determine dynamically if a transaction is to be executed pessimistically comprises to determine during runtime execution at the entry boundary to the transaction if the transaction is to be executed pessimistically based on a transactional characteristic associated with the transaction. ### Claim 3 (depends on 2) The system of claim 2, wherein the transactional characteristic is selected from a group consisting of a number of failures associated with the transaction, a performance heuristic associated with the transaction, a privatization nature of the transaction, an irrevocable nature of the transaction, and an obstinate nature of the transaction. ### Claim 4 (depends on 1) The system of claim 1, wherein to determine dynamically if a transaction is to be executed pessimistically comprises to determine during runtime execution, part-way through the transaction, that the transaction is to be executed pessimistically. ### Claim 5 (depends on 4) The system of claim 4, wherein the program code, when executed, is further to validate a read set for the transaction and acquire pessimistic shared read locks for reads within the read set for the transaction in response to determining during runtime execution part-way through the transaction that the transaction is to be executed pessimistically. ### Claim 6 (canceled) ### Claim 7 A method comprising: determining during runtime execution of program code including a first transaction that the first transaction is to be executed optimistically; determining during runtime execution of the program code including a second transaction that the second transaction is to be executed pessimistically; and executing, at least partially in parallel, the first transaction optimistically and the second transaction pessimistically, wherein executing, at least partially in parallel, the first transaction optimistically and the second transaction pessimistically comprises acquiring a pessimistic write lock and subsequently an optimistic write lock in a transaction record associated with a memory address referenced by an optimistic transactional write operation before performing the optimistic transactional write operation to the memory address. ### Claim 8 (depends on 7) The method of claim 7, executing, at least partially in parallel, the first transaction optimistically and the second transaction pessimistically further comprises performing optimistic read barrier operations at an optimistic transactional read within the first transaction and performing pessimistic read barrier operations at a pessimistic transactional read within the second transaction. ### Claim 9 (depends on 8) The method of claim 8, wherein the optimistic read barrier operations include checking an optimistic concurrency control field of a transaction record associated with a memory address referenced by the optimistic transactional read to determine if the memory address is not exclusively locked, and wherein the pessimistic read barrier operations include checking a pessimistic concurrency control field of the transaction record associated with the memory address also referenced by the pessimistic transactional read to determine if the memory address is not exclusively locked. ### Claim 10 (depends on 7) The method of claim 7, wherein determining during runtime execution of the program code including a second transaction that the second transaction is to be executed pessimistically is in response to determining the second transaction is to be executed as an obstinate transaction. ### Claim 11 (depends on 4) The system of claim 4, wherein to determine dynamically if the transaction is to be executed pessimistically comprises to determine that a transaction is to be executed pessimistically during runtime, part-way through the transaction, in response to an optimistic read barrier failing a predetermined number of times during previous execution of the transaction. ### Claim 12 (depends on 4) The system of claim 4, wherein the program code, when executed, is further to acquire exclusive ownership of pessimistic fields of transactional records for previous reads of the transaction in response to determining that the transaction is to be executed pessimistically during runtime, part-way through the transaction. ### Claim 13 (depends on 1) The system of claim 1, wherein to determine dynamically if the transaction is to be executed pessimistically comprises to determine dynamically if a transaction is to be executed pessimistically in response to execution of an optimistic read barrier. ### Claim 14 One or more non-transitory machine-readable storage media comprising a plurality of instructions stored thereon that, in response to execution, cause a computing device to: determine dynamically if a transaction is to be executed pessimistically; and modify a pointer of an indirect call to an optimistic read barrier for a transactional load operation within the transaction to call to reference a pessimistic read barrier in response to determining dynamically the transaction is to be executed pessimistically. ### Claim 15 (depends on 14) The one or more non-transitory machine-readable storage media of claim 14, wherein to determine dynamically if the transaction is to be executed pessimistically comprises to determine, during runtime execution at the entry boundary to the transaction, if the transaction is to be executed pessimistically based on a transactional characteristic associated with the transaction. ### Claim 16 (depends on 15) The one or more non-transitory machine-readable storage media of claim 15, wherein the transactional characteristic is selected from a group consisting of a number of failures associated with the transaction, a performance heuristic associated with the transaction, a privatization nature of the transaction, an irrevocable nature of the transaction, and an obstinate nature of the transaction. ### Claim 17 (depends on 14) The one or more non-transitory machine-readable storage media of claim 14, wherein to determine dynamically if the transaction is to be executed pessimistically comprises to determine during runtime execution, part-way through the transaction, that the transaction is to be executed pessimistically. ### Claim 18 (depends on 17) The one or more non-transitory machine-readable storage media of claim 17, wherein the plurality of instructions further cause the computing device to validate a read set for the transaction and acquire pessimistic shared read locks for reads within the read set for the transaction in response to a determination during runtime execution part-way through the transaction that the transaction is to be executed pessimistically. ### Claim 19 (depends on 17) The one or more non-transitory machine-readable storage media of claim 17, wherein to determine dynamically if the transaction is to be executed pessimistically comprises to determine that a transaction is to be executed pessimistically during runtime, part-way through the transaction, in response to a determination that an optimistic read barrier has failed a predetermined number of times during previous execution of the transaction. ### Claim 20 (depends on 17) The one or more non-transitory machine-readable storage media of claim 17, wherein the plurality of instructions further cause the computing device to acquire exclusive ownership of pessimistic fields of transactional records for previous reads of the transaction in response to a determination that the transaction is to be executed pessimistically during runtime, part-way through the transaction. ### Claim 21 (depends on 14) The one or more non-transitory machine-readable storage media of claim 14, wherein to determine dynamically if the transaction is to be executed pessimistically comprises to determine dynamically if a transaction is to be executed pessimistically in response to execution of an optimistic read barrier.