Designing An Analytical Framework For Software Transactional Memory

Ramanuj Bhattacharyya
Principal Engineer, Interra Systems India Pvt. Ltd., Kolkata, India. ramanuj@cal.interrasystems.com library of the target computer to implement high-level parallel constructs. The pre-compiler approach like automated Alliant FX FORTRAN compilers, DINO, PAT, MIMDizer, on the other hand require some program flow analysis, dependence checking and limited optimization towards the parallelism detection. The third approach demands a fully developed parallel or vector compiler which can automatically detect parallelism in source code and transform the sequential codes to parallel constructs [1]. To be honest, several efforts have already been made to implement the practical approach towards the transactional memory [13][14][15][16][17]. Additionally several third party tools are already available freely in the internet. Unfortunately, after the so many amounts of efforts, no such concrete analytical model has been proposed for the TM systems. The uniqueness of the proposed strategy lies within the generic analytical view of the STM systems. So far dug in the depth about the proposed strategy, this is probably the first such effort towards the analytical implementation of the transaction memory architectures. From that point of view, the current effort is probably unique to the best of authors knowledge. It tries to see the TM system from an analytical viewpoint. Analytical in the sense it establishes a premathematical model of Software Transactional Memory. The transaction has been represented as the combination of 10 tuples. It also defines the basic set of operations that a transaction in a multi-core architecture must have. Additionally, some operators and notions of the complete model have also been derived from the detailed analysis. II. A STEP TOWARDS TRANSACTIONAL MEMORY In 1978 C.A.R Hoare wrote, developments of processor technology suggest that a multiprocessor machine may become more powerful, capacious, reliable, and economical than a machine which is disguised as a monoprocessor [5]. His assumption has proved to be concrete today. Among the several proposed concurrency control strategies: locks, wait free synchronization, Pthread mutexes, Semaphores are the major ones. Parallelism has not only been incorporated in the language constructs, but also several parallel programming environments like Cray Y-MP software, Intel Paragon XP/ S software, Cm-5 etc have been invented to utilize the flavor of parallelism[1]. The transactional memory approach is an effective alternative to the lock based approach. The domain of

Abstract The recent growth in the design of advanced computer architecture has shifted from the concept of single core processing environment to the multi-core processors. Several processors work together in strong collaboration between each other to accomplish a task. A sequential compilation process will be inefficient in this kind of machines as it cant utilize all the available processors. Keeping that flaw in mind, in this paper an approach has been designed to develop a analytical framework for these parallel computers. Section I gives a brief introduction of the overall approach and discusses the uniqueness of the approach. Section II summarizes the basic concepts of Transactional Memory. In section III, an analytical definition of the transaction has been depicted. Section IV explains the preliminary sets of operations that a transaction must have for the multi-core processors. In section V, the complete concept along with the idea of the several principles has been summarized. It also defines the basic sets of operations and a complete set of notions for an ideal STM system. And last but not the least, in section VI, the conclusion and further scope of the work has been explained. Keywords-component; STM/ HTM; UTO, Features, Operators, Notions, Principle of Granularity, Principle of Integration.

I.

INTRODUCTION

Modern computer systems have evolved from the single core to many-core architecture due to the ever increasing demand for the higher performance, lower costs, and sustained productivity in real life applications. Among the so far designed strategies, parallelism appears in several forms like look-head, vectorization, concurrency, pipelining, partitioning, simultaneity, data parallelism etc. In this paper an attempt has been made to utilize the full flavor of parallelism in the analytical point of view. In a chunk of code, several relationships might exist among the different parts of the program. They might or might not be dependent on each other or they may be accessing the same parts of the code fragment at the same time causing the access to a particular variable simultaneously. So, there is a specific need to synchronize the access to these segments in the multi-core processors. So far the proposed approaches, the parallelism are utilized depending on the predefined language constructs. These high level constructs can be implicitly embedded in the syntax or explicitly specified by the user. Among such approaches, the most widely used are pre-processor, pre-compiler and parallelizing compilers. A pre-processor like FORCE, MONMACS etc use a sequential compiler and a low level

flexibilities that the TM systems provide is quiet larger compared to the traditional lock based or monitor/ semaphore based systems. It provides various options like check-pointing, roll-back, commit, abort etc to make the system stable in case of the result of the transaction is not as expected or some processors have failed during the execution causing the overall transaction as the failure ones. The concept of TM System has been borrowed from the traditional transaction mechanism of the Database Systems. It groups a segment of code in such a way, that only one processor gets access to segment at any instant of time. So, there will be no conflict for the sensitive flow of code. To achieve this, for any kind of transactional memory, three basic characteristics are required to be satisfied it is called the ACI property of the transaction: Atomicity: Either all or no instruction in the block will be executed. Consistency Preservation: The complete execution of the transaction takes the system from one complete state to another complete state. Isolation: Until transaction ends, its result is not publicize to the other segments of code. Several proposals like, data versioning, weak/ strong isolation, nested transaction etc have already been proposed to achieve different features of the TM systems [10]. The only difference between the transaction system in database and the multi-core systems is: database transactions are completely isolated and they dont have the privilege to access the non-transactional code base. In contrast to that, the architectural TM systems have to deal with the access to both the transactional and nontransactional memory segment. This is called strong and weak isolation depending upon the memory access across the transaction boundaries. Additionally a transactional system can also be termed as the nested TM if it is embedded within another transaction. There are two kinds of nesting: Open and closed nested TM system. The former one publishes the state of an inner transaction in case the outer transaction aborts whereas closed nesting discards the changes from the inner transactions causing no side effects[13]. III. ANALYTICAL DEFINITION OF TRANSACTION A Transaction is defined by the 10 tuple: <Tid, Procid, V, [N], WItem, RItem, W, R, Co, Ao> id Where, T = Transaction id. Procid = Processor id to which the transaction is assigned. V = Set of variable defined within the transaction. [N] = Number of children/ nested transaction within it. WItem = Set of shared variable written within the transaction. RItem = Set of shared variable read within the transaction. W = Set of defined write operations within the transaction. R = Set of read defined operations within the transaction. Co = Commit and defined operations after that. Ao = Abort and defined operations after that. IV. UTO OF A TM SYSTEM For any TM Model, the paradigm must define some of the operations those are fixed for any kind of transactions. These have been entitled as UTO of a transaction. UTO stands for

Universal Trunk Operations these are the preliminary set of operations that a paradigm must define to make the complete transactional memory model. These are: 1. INIT_TRANSACTION(T,P,W,R): Functionality: Initiates a transaction. Arguments : o T: Unique identification of a transaction. o P: Processor id to which the transaction will be allotted. o {W}: Set of allowed modification accesses. o {R}: Set of allowed read accesses. 2. INIT_TRANSACTION(T,W,R, Prop): Functionality: Initiates a transaction. Arguments : o T : Unique identification of a transaction. o {W}: Set of allowed modification accesses. o {R}: Set of allowed read accesses. o Prop: A container object that defines some of the basic optional features of the transaction, like IS_NESTED, IS_W_ISOLATED, IS_O_NESTED, IS_C_NESTED etc. 3. STORE_STATE(T): Functionality: Stores the state of the system prior to entering a transaction.. Arguments : o T : Unique identification of a transaction. 4. RESTORE_STATE(T): Functionality: Restores the state of the system after aborting a transaction.. Arguments : o T: Unique identification of a transaction. 5. READ_DATAM(T,MEM_OBJ): Functionality: Reads value of the memory location.. Arguments : o T: Unique identification of a transaction. o MEM_OBJ: Address of the memory location. 6. WRITE_DATAM(T,MEM_OBJ,VAL): Functionality: Write a value in the memory location.. Arguments : o T: Unique identification of a transaction. o MEM_OBJ: Address of the memory location. o VAL: Value to be written. 7. COMMIT_TRANSACTION(T): Functionality: Commit the transaction. Arguments : o T: Unique identification of a transaction to be committed. 8. MAKE_PERMANENT(T): Functionality: Log the current state of the system as the permanent state. Arguments : o T: Unique identification of a transaction whose effect is required to be mark as permanent. 9. ABORT_TRANSACTION(T): Functionality: Aborts the transaction.. Arguments :

T: Unique identification of a transaction to be aborted. 10. CLOSE_TRANSACTION(T): Functionality: Marks the transaction as terminated. Arguments : o T: Unique identification of a transaction to be committed.

V.

PROPERTIES OF THE MODEL

To map the complete system in a mathematical model, two principles have been proposed in this paper. These are called (1) Principle of Granularity and (2) Principle of Integration. These two principles, in collaboration with each other, define the mathematical base of the overall system. Principle of Granulairity: Under this principle, several root level properties of the entire mathematical model have been defined - these are called the features and operators. Features are the properties that can be modeled through straight forward notion and proper explanation. It is not the mandatory property of the overall paradigm rather it is called the desirable property of the system. Operators are mathematical operations defined by the proposed Analytical paradigm all these must have to be satisfied to make the overall system a complete TM model. A. Operators: Theory of Equality: Two transactions are said to be equal if they are derived from the same base transaction and operate on the same code fragment. It is denoted as operator A B implies both the transactions are basically spawned from a single transaction and confined around the same segment of textual code. Theory of Identity: Two transactions are said to be identical (but not equal) if they operate on same set of shared variable. It is denoted as operator A B implies both the transactions operate on the same set of shared memory object. Theory of Optimality: A transaction is said to be optimal that all other transaction if it touches minimum number of variables to detect the critical section of the execution. Also to induce another constraint, it should change the minimum amount of code to preserve the restricted concurrency. It is denoted as - A B implies A requires less amount of information mapping to find out the critical section region. Theory of Pervasiveness: If a transaction has started, it will pervade through the complete execution session until and unless the transaction commits/ aborts or the process terminates. In the latter scenario, there should be a mechanism by means of which the throughput of the transaction can be written back to the disk to shift the system's state to a stable one. It is denoted as the unary operator - A implies the transaction will persist throughout the existence of the process. Theory of Constructiveness: The transaction should be having the capability to find out the critical section of the 1.

code base by their own. The programmer might mention the CS as the explicit implication. The Analytical paradigm should be having the capability to find out such a CS region implicitly if it detects that some memory segment might have been shared or might be shared among the several concurrently executing processes. It is denoted as - A implies the system either can start a transaction entitled as A or the started transaction can point out the CS region not detected by the programmer. Theory of Nesting: If a transaction has been fenced completely within another transaction, the former one is called nested transaction and the latter one is called the parent transaction. It is denoted as - A B implies B is a nested transaction within A. o Theory of private nesting: In case of private nesting the result of the innermost transaction are not exposed to the existing system until the parent transaction commits or aborts. If the parent transaction commits, the complete result is written back to the system, otherwise the complete result is thrown and the system is restored back to last stable state. It is denoted by * - A * B implies B is a privately nested transaction within A.
o

Theory of public nesting: In case of public nesting, as soon as the child transaction commits, it's result is written back to system. It does not wait for the completion of the parent transaction. It is denoted by # - A # B implies B is a publicly nested transaction within A.

Theory of Orthogonality: Two transactions are said to be orthogonal if they are mutually independent, nonredundant, non-overlapping, or irrelevant. The proposed Analytical paradigm should be orthogonal in the sense that its features can be used without thinking about how that usage will affect other features. It is denoted by the binary operator - A B implies, A and B are two orthogonal transaction. Theory of conjecture: The paradigm should support the flexibility to predict the result of the transaction in case it has not committed or aborted. Depending on that the program can take a greedy move and shift to another control flow depending on the result. It is denoted as the unary operator ? - ?A implies the result of the transaction A can easily be guessed. Theory of Isolation: If the transaction has started, it must not be interfered by any other transaction. Either it will complete the execution and commit or it will rollback to the previously saved stable state. It is denoted by the operator |+ - A |+ B is a Boolean operation and should always return false. It implies that A and B are any two transaction that can't be executed in an interleaved manner. Theory of Personalization: The paradigm should be capable enough of customizing the overall features of the system. It is defined by the feature @ - let S = {S1, S2, ....., SN} is the complete set of features defined the system

and also supported by the paradigm. If, due to some reason, the system might have to add or remove or enhance some of the features, the resultant feature set would be exhaustive enough to support all the feasible requirements of the basic TM system. In the mathematical model, S @ (SJ S) = Snew S, where = not belongs to. That is a feature defined by Sj, which is not part of S, would give rise to another feature set and it is not equal to S. Theory of Scalability: The Analytical paradigm should not be having any limitation on the number of concurrently executing processes. That is for all AI, I = {1,2, .., }. Theory of Atomicity: If a transaction has started the execution, either it will finish completely and commit the result or it will abort the current changes. In the former scenario, the system will be in a stable state after the execution in the latter scenario the state just prior to entering the transaction will be rolled back. It is the property of a TM system and denoted as : {A}. It implies A can't stop without taking a accepted decision of it's execution. Theory of Confidentiality: A transaction must not reveal it's current state as well as result prior to it's completion. In the mathematical model, it is denoted as [A]. It simply implies the transaction is shielded from the external world. Theory of Durability/ Persistence: The proposed Analytical paradigm must be having the capability to store the result permanently back in to the system. The result must not be destroyed under any circumstances, even after the system failure. It is denoted as the unary operator => - A => implies the transaction has committed it's result and it should be permanent in the underlying engine. Theory of Locality: Any variable defined within the transaction should be visible only within that transaction. In the programmers' point of view, it simply defines a scope and all the declaration within that is not visible outside of that scope. It is denoted as the binary operator - for any x, x A = true implies x is variable declared within the transactional scope A and it is local to that scope. Theory of Union: If the concurrency achieved by the two individual transactions are not enough to keep the system in s stable state, the paradigm might try to merge these two transactions with the combined effect overall. If that combined effect is adequate to decide the system's state, the proposed paradigm will merge these two. It is denoted as the binary operator U A U B implies A and B are two such transaction, whose cumulative effect will make the system a stable one. Theory of Intersection: If two transactions are intersecting at any point of time, the system must decide which of the two will execute quiet natural the other one will move to the recessive phase. The reason of such behavior is the Theory of isolation as stated above no two

transactions can affect the execution of another transaction. It is denoted as the binary operator A B implies A and B are two intersecting transactions. Theory of Restoration: In case the transaction has failed, it should restore back the previously saved stable state. Before entering the transaction, the programming paradigm must store the current state of the system. It is denoted as the unary operator - A implies the system is entering within a transaction pointed by A in case A has failed, restore the system back to the state just prior to A. Theory of Staircase wise development: The paradigm must support the incremental development and execution of the transaction. If the transaction is executing behind the abstraction of another function, then these transactions can be executed in a step by step fashion. Also, the paradigm should be capable of adding new features without hampering the existing code base. Theory of Robustness: The paradigm should be boisterous enough so that it can support the wide range of features defined by the traditional TM system. It should be capable of supporting all the features of the so called transactional system like Atomicity, Isolation, and Confidentiality etc. Theory of Reasoning: A valid reason must exist for all kinds of transition within the domain. The underlying Analytical paradigm must be capable enough to mathematically establish all the state flow/ state chart models of the overall system. There must not be any kind of state changes that is not explainable by the derived notions in the next section. Theory of Compression: The Analytical paradigm should be intelligent enough to reduce the number of concurrent transactions defined by the programmer in case it decides the same is achievable by the lesser number of transactions. Theory of Efficiency: A transaction must not impose unacceptable overhead on the entire execution process. In fact in complete code base there are several sections that do not use the transaction this non transactional segment must not be affected by the transactional segment. Also, while switching between the CS and non-CS region, the context switching should not affect the overall complexity of the system. Theory of Extensibility: The Analytical paradigm should be intelligent enough to increase the number of concurrent transactions defined by the programmer in case it decides the same is not achievable by the defined number of transactions.

B. Features:

Principle of Integration: Under this principle, several notions have been derived that can be proved and constructed as well, with the help of the above mentioned features and operations. These are the basic composite properties of the overall system and must be

2.

supported by the ideal mathematical paradigm. The target is to establish the traditional transaction programming characteristics to prove the completeness of the overall system. Notion 1 - Principle of serializability: Two parallel transactions can be replaced by an equivalent serial sequence. Proof of concept: If two transactions are being executed in an interleaved fashion, there must exist a serial sequence that can be executed in place of those two transactions. If the generated sequence gives a stable and committable output, the interleaved execution of the two transactions can also produce the same. Similarly, if any or both of them abort, the parallel transaction(s) will also fail in the same way. Regarding the mathematical derivation, the principle can be explained as: i, {Xi} U {Yi} = {KK (K+1)(K + 1)_} {{CX,CY},{CX,AY},{AX,CY},{AX,AY}}. It implies, two atomic transactions, Xi and Yi can be replaced by the sequence of operations denoted as K and K followed by the set of terminal functions like C{X,Y} and A{X,Y} denoting the abort of the transaction X and Y respectively. Notion 2 - Principle of Non-Overlapping: The write intersection set of two parallel transactions is always an empty set. Proof of concept: If two transactions are being executed simultaneously, they might be having any operation involving shared variable of the combination RR RR stands for Read-Read Operations. That is if Xi and Yi be two transactions, then to be a valid transactional paradigm there should not be any combination of operations where any of the operations is a write operation. Regarding the mathematical derivation, the principle can be explained as: i, {Wi} X {Rj} = = { }, i = 1,2,3 .. N. i, {Ri} X {Wj} = = { }, i = 1,2,3 .. N.
i j i j

i, {R } X {R } = = {R R }, i = 1,2,3 .. N. For the simplicity, all the operations have been considered on the same variable. Hence, the complete set of allowed operations S is defined as: S = {{Wi} X {Rj}} U {{Ri} X {Wj}} U {{Wi} X {Wj}}

i, {Wi} X {Wj} = = { }, i = 1,2,3 .. N.

U {{Ri} X {Rj}}, i, & j, i,j = 1,2,3 .. N. Notion 3 Principle of Persistency: The system is always in stable state at any point of the transaction. Proof of concept: Prior to entering a transaction, the current state of the system is stored in the log. In case the transaction has aborted, the backed up log will be flushed and system will return back to the old state. If the transaction has committed, the system will be having the most stable state that would be written and maintained as the last updated log for the next transaction. This concept is prerequisite for Notion 4 and 5. If we map the

operations in some graphical model, at any point there are three paths are available: o Transaction goes to the next possible operation. o Transaction aborts and o Transaction commits. If transaction chooses the second option, it is always having the last stable state at the memory - it will simply discard all the operations done by the aborted transaction and writes back the logged data on the stable storage device. Notion 4 Principle of Back Annotation: If a transaction has committed, it is never required to be rolled back. Proof of concept: If a transaction has completed successfully and its result has been written on the memory, at that instant of time the system is considered to be stable. So, no such scenario must exist, for which the entire result is required to be rolled back. Once it has been checked in, it is assumed that the system is in stable state at the end of the transaction. Here comes the concept of complete sequence. A schedule S = T1 || T2 || T3 || T4 .TN, is said to be completely scheduled if it satisfies the following criteria: o The schedule can be broken in a sequence of read and write operations. o The commit and abort are the last operation in the sequence for a particular transaction. o The operations in s are exactly the same operations those are defined in individual transaction, i.e., |S| = |{T1W U T1R U C1 UA1} U {T2w U T2R U C2 UA2} U U {TNW U TNR U CN U AN}| o The sequence of any two operations in a particular transaction is same as the overall sequence. Under these scenarios, if any abort occurs for a particular transaction, the effect of that transaction will be removed from the system memory and a new schedule will be defined with a old set of operations excluding the operations of the aborted transaction. By this way, recursively we can go to stable set of complete serial schedule. Notion 5 Principle of Recoverability: For a set of perfectly scheduled set of transactions, no transaction is required to be rolled back. Proof of concept: A schedule S of N transactions is said to be perfectly scheduled if it satisfies the concept of complete sequence in Notion 4 and along with that, the following three criteria are also met: o If T1 and T2 are the two transactions with T1 || T2, T2 reads an item X that T1 writes, and then T2 must not be committed until and unless T1 commits. o If T1 and T2 are the two transactions with T1 || T2, T2 reads an item X that T1 writes, and then T2 must and ought to be aborted if T1 aborts. o If T1 and T2 are the two transactions with T1 || T2, T2 reads an item X that T1 writes, and then there must not be any transaction T3 that reads and updates the value of X after the modification caused by T1 and before the read caused by T2.

If T1 and T2 are the two transactions with T1 T2, T1 reads an item X that T2 writes, then T1 must restore the value of X if T2 aborts. o If T1, T2 and T3 are the two transactions with T1 T2 and T1 T3, T3 reads and updates an item X that T2 writes, and eventually if T1 reads and updates the item, then T1 must restore the value of X if T2 if aborts. It will at the same time cause T3 to abort. Notion 6 Principle of Opacity: A transaction always observes a consistent version of the system. Proof of concept: This is one of the correctness criteria for the TM system. [18] has defined the concept in an elaborated way. As the basic notion of opacity, it must satisfy three criteria: o Each of the operations performed by every committed transaction appears as if they happened at some single, indivisible point during the transaction lifetime. o None of the operations performed by any aborted transaction is ever visible to other transactions and o All transactions always observe a consistent state of the system. In a nutshell, it simply assumes a cautious approach that ensures the systems stability at any point of time. Notion 7 Principle of Contention: Only one instance of a shared resource is allotted at any instant of time. Proof of concept: For any parallel schedule S = T1 || T2 || T3 || T4 .|| TN, only one transaction at any instant of time will be assigned the write permission to a data item X. By this was the vulnerability to concurrency can be removed as there will be no concurrent modification of same memory location. However the concurrent read operations might be there. That is if WT4(X) is allotted, WTK(X), for any K = 1,2, . N and K 4 is never executed until WT4(X) gets completed. Notion 8 Principle of Paternity: Sole Paternity: If any of the child transactions within a parent transaction fails and if that is having some write operation, the entire parent transaction will fail. Induced Paternity: If any of the child transactions within a parent transaction fails, the former one will abort and parent will proceed to next child. Proof of concept: It summarizes the parental relationship among the two transactions. There is another term Ancestors has been defined in Notion 16. The basic difference between these two is Ancestors define the transaction that is executed and committed/ aborted prior to the Predecessor transaction. That is T1 is the ancestor of T2 in case T1 completes its execution, by any means prior to T2. But, the parent defines the transaction that embeds the child transaction within itself. Figure 1 elaborates the concept of paternity. In top segment, as soon as T2 terminates prematurely, the entire parent transaction T gets aborted. This summarizes the sole paternity. For induced paternity, after the premature termination of T2, parent T continues the execution and unlock T3 with its further execution steps. o

Mathematically, the following Cartesian product would always generate an empty set: {T1{W} U T1{R}} X {T2{W} U T2{R}} X {T3{W} U T3{R}} {C1,A2} {AT} = It explains the sole paternity. As per the notation, If transaction T2 aborts after the all possible combination of operations of all the three transactions, the parent T will be aborted and its result will be rolled back to the last stable state. Hence, eventually it creates an empty set. For the induced paternity, the equation would be: {T1{W} U T1{R}} X {T2{W} U T2{R}} X {T3{W} U T3{R}} {C1,A2, C3} {CT} = S, where |S| > 0. Just as previous, if the T2 aborts, T will choose the transaction T3 at the end the parent will commit successfully by creating a non-empty set of result.
Read(Y) T3 Read(X) T2 Write(X) T
1

Write(Y)

WAIT Write(X) Abort

Commit

X
Write(X)

Entire Transaction T is aborted.

T
T
3

Read(Y)

Write(Y) Read(X)

WAIT Write(X) Abort

Read(X)

Commit

T2 Write(X) T1 Commit

T is allowed to proceed with child T3 .

T Figure 1: (a) Sole paternity & (b) Induced paternity.

Notion 9 Principle of Preemptive Election: A transaction with some more prioritized characteristics will be executed first by forcefully aborting the lesser one. Proof of concept: This is a greedy optimization that would cause the system to be deadlock free under any condition. However the obtained result might differ from the expected one. For a multi-core processor system, if the scenario is such that two processors are somehow dependent on each other and both of them are waiting for the completion of other one, the system will be in the deadlock. Under this proposal, on the basis of some priority, any one of the processors will be elected and declared as the winner. It will carry on the normal execution and other one will be aborted by undoing all its modifications. From the Databases perspective, several deadlock prevention schemes like Timeout, starvation have already been proposed and well defined. But none of the ideas has been elaborated from the angle of many core architectures. Notion 10 Principle of Validity: All the operations performed by the transaction are valid, indispensable and indivisible units. Proof of Concept: It models the validity and consistency of a TM model. Three aspects are there. First of all a transaction must not model any functions that might make the state of the system unstable. Secondly, all the operations of a transaction are unavoidable. Additionally,

if a transaction has initiated an operation, that must have to be completed to shift to the next unit of operation. Notion 11 Principle of Reference: The interaction between the transactional and non-transactional code must be synchronized. Proof of concept: There must be some access trade off between the access between the transactional and nontransactional code. A transactional and non-transactional code may access each other. That say a variable declared outside the transactions CS region may be accessed within the transaction. At the same time value of the variable updated in between the transaction may have been accessed by another non-transactional code. [16][17] have already given some notion of the scenario but till now no such solid mathematical model has been proposed on it its clearly an open area of research. Notion 12 Principle of Privatization: Transactional code and memory segments defined within the transaction are always private to the outer world. Proof of Concept: A transaction defines a scope of locality within the transaction. So, any variable or memory segment defined within the transaction is only accessible within the boundary of the transaction. However, the transaction can access the variable defined outside and prior to the transaction. Although the access is restricted, but the privilege is given for the letter kind of access. Hence, if a transaction has been defined as the 10 tuple: <Tid, Procid, V, [N], WItem, RItem, W, R, Co, Ao> (Section III), then for the variable x defined within the transaction, (x A) is always true in general:

the latter scenario, the backup storage is flushed as the current stable state in case the transaction commits and rejection as it is if the transaction fails. The first one is termed as the eager versioning and the latter one is called the lazy versioning.
Backed up System State C T W M A M M

System Storage Memory C T W M A

Figure 2(a): In place writing. (b) In buffer writing.

M M

Notion 14 Principle of Adaptability: The paradigm is always adaptable to the more CS region coverage by optimal amount of transaction. Proof of Concept: This is the direct derivation of Principle of Union, compression and extensibility. If several equal and identical code fragments have been fenced by some set of transactions, it is always possible to derive a subset of transaction that enables to achieve the same level of isolation by the initial two exhaustive sets. CS1 Common Operation Set CS2

x, (x T) =

1 0

for x V for x V

For all such 1 values, in case of another transaction T1, R(x) and W(x) are strictly prohibited and will be thrown an exception by the model in case forcefully called. Notion 13 Principle of Versioning: The paradigm is capable to keep the system in a stable state at any instant of time. Proof of Concept: This is directly derivable from the facts of Commit and Abort Transactions. As described earlier, a system should be updated as soon as a transaction terminates it may be updated forward or may be updated backward depending on the transaction result type. Hence, during the transaction, the system must be having some way to keep the log of the current transaction. It may backup the last stable state and update the values directly in the respective memory location or it may update the memory location in backup storage and keep the current memory location unchanged. In the former scenario, the last stable state will be modified in case the transaction commits or the last stable state will be flushed as the current stable state in case the transaction fails. For

CS1 is continued CS2 is halted and restarted after closing CS1

Figure 3: Intersection transaction flow in Critical Section.

Regarding the mathematical derivation, the Principle can be explained as: If TA = {TA1, TA2, TA3, ., TAN}, TB = {TB1, TB2, TB3, ., TBN} and TA TB or TA TB
B B B B B B B

the veto on non-identical set of composition, i.e., TAi TBi = is both TAi and TBi are identically having the same set of operations and operates on same CS region or the transaction with optimal set of operation that causes the same effect as TAi U TBi.

TB. is defined as the logical operation that always gives

B

then TAB = (TA TB) such that, TAB TA and TAB

B

Notion 15 Principle of Commonality: Common segments among the two transactions are always mutually exclusive. Proof of concept: If two transactions are operating on two different Critical Sections, they can execute in parallel fashion until they are having some operation that involves same portion of any of the critical sections. In this case, even in multi-core processors, depending on some scheduling criteria, one transaction will continue its execution and the other one will be halted the latter one gains the CS only after the former one exists from it. That is, if TA || TB and CS1 CS2 = {CS12 } and |CS12| > 0, the equivalent parallel schedule would be: TA {S1} X {CAAA } TB {S1} X {CBAB} WA1 RA1 WA2 RA2 RA3 WA3 {CAAA } St(TA) St(TB)

VI.

CONCLUSION

The above mentioned analytical model of TM system establishes a complete framework for the transactional memory in a multi-core processor. To be honest, there is still enough further analysis is required to establish the concrete analytical model of a TM system. The very next step of the current proposal would be deriving a graphical view of the complete set of transactions for a multi-processing system. It is quiet easy to visualize a set of transaction as the nodes in a graph and the edges as the dependency among themselves. The in-degree of a node simply models the Principle of Linearity. Similarly, out-degree of a node models the Principle of Serializability. Due to the space limitation, it was not possible to give an overview of that however it will be published in the fore coming publications. REFERENCES
[1] Advanced Computer Architecture Parallelism, Scalability, Programmability, Kai Hwang, Prof. Electrical Engg, University of Southern California. Contention Management in Dynamic Software Transactional Memory, William N. Scherer III and Michael L. Scott Department of Computer Science, University of Rochester. Nested Transactional Memory: Model and Preliminary Architecture Sketches, J. Eliot B. Moss, Department of Computer Science, University of Massachusetts, Amherst Amherst, MA 010039264, USA & moss@cs.umass.edu, Antony L. Hosking, Department of Computer Science, Purdue University, West Lafayette, IN 47907, USA. Adaptive Software Transactional Memory, Virendra J. Marathe, William N. Scherer III, and Michael L. Scott, Department of Computer Science, University of Rochester, Rochester, NY 14627-0226. C. A. R. Hoare. Communicating sequential processes. Communications of the ACM, 21(8):666677, 1978. The Software Stack for Transactional Memory Challenges and Opportunities, Brian D. Carlstrom JaeWoong Chung, Christos Kozyrakis Kunle Olukotun, Computer Systems Laboratory, Stanford University. J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques. Morgan Kaufmann, 1993. Wikipedia www.wikipedia.org. Boost community generic programming www.boost.org/community/generic_programming.html. http://sourceforge.net/projects/fastdb/. http://www.oracle.com/technology/products/timesten/index.html. System challenges and opportunities for Transactional memory, PhD Dissertion, JaeWoong Chung, 2008. Towards Transactional Memory Support for GCC - Martin Schindewolf, Albert Cohen, Wolfgang Karl, Andrea Marongiu, and Luca Benini. Towards Transactional Memory Semantics for C++ - Tatiana Shpeisman, Ali-Reza Adl-Tabatabai, Robert Geva, Yang Ni, Adam Welc. Executing Java Programs with Transactional Memory - Brian D. Carlstrom, JaeWoong Chung, Hassan Chafi,, Austen McDonald, Chi Cao Minh, Lance Hammond, Christos Kozyrakis, Kunle Olukotun, Computer Systems Laboratory, Stanford University. Integrating Transactional Memory into C++ - Lawrence Crowl, Yossi Lev, Victor Luchangco, Mark Moir, Dan Nussbaum - TRANSACT 2007. C. Blundell, E. Lewis, and M. Martin. Deconstructing transactional semantics:the subtleties of atomicity. In Proc. Annual Workshop on Duplicating, Deconstructing, and Debunking (WDDD), June 2005. On the Correctness of Transactional Memory, Rachid Guerraoui Micha Kapaka School of Computer and Communication Sciences, EPFL, frachid.guerraoui, michal.kapalkag@ep.ch.

WB1 RB1 WB2 WB3 xxxx xxxx xxxx xxxx RB2 RB3 {CBAB }

[2]

TB waits until TA completes.

[3]

[4]

[5] [6]

Figure 4: Equivalent parallel schedule for two parallel transactions

Where St(T) = Start of a transaction. W = A write operation, R = A read operation. Just notice in the above parallelized schedule, the transaction B halts at some instant of time until transaction A terminates (Commits or aborts). Notion 16 Principle of Linearity: A transaction can only start only after the completion of its ancestor transaction. Proof of concept: There is one basic difference between the ancestor and parent transaction. The concept of parent transaction is only valid if the current transaction is embedded within another transaction. Where as, the ancestor transaction is the transaction defined and scheduled to be executed prior to the current one. If the ancestor has not finished its execution and committed/ aborted the result, the predecessor cant start its execution. Regarding the mathematical derivation, the principle can be explained as:
i, {TA } =
i

[7] [8] [9] [10] [11] [12] [13] [14]

[15]

[16]

{
i-1

when i = 0 {TAi} U {TAi - 1} when i 0.

i-1

[17]

[18]
i i

TA {S

} X {C

i-1

} TA {S } X {C A }