The control flow is an important feature of a programming language. The transactional nature of transaction blocks has implications on the behaviors of regular control flow key- words and the exception throw that already exist in the Java language. Additionally, being part of the language, the transaction abstraction introduces new control flow behaviors tied to the transactional behavior. We, hence, present three types of control flow constructs related to transactions aiming to satisfy all these requirements: regular, transactional and exceptional control flow.
5.4.1 Regular control flow constructs
The semantics for usual control flow statements are kept as close as possible to their original semantics. The break, return and continue statements can be used to transfer control out of a transaction while switch statements must not be used to transfer control into a transaction statement. With these requirements our language specification follows closely the C++ specification (see Section C.5.1).
5.4.2 Transactional control flow constructs
The Java language extension tries to take advantage of transactional behaviour for the use of programmer in different possible ways. With this objective it proposes two types of control flow constructs: alternative execution paths, and novel transactional control flow keywords.
5.4.2.1 Alternative execution paths
The Java language extension specification introduces a language construct, which does not exist in the C++ specification, to enrich transactional control flow: alternative execution paths. An alternative execution path can be considered to correspond to a case statement of a switch-case statement that resides in a transaction statement. The main difference is that an alternative execution path comes with an additional transactional semantics: at any point inside an alternative execution path the modifications performed by the enclosing
transaction statement can be rolled back and the transaction statement can be re-executed using another alternative execution path.
Alternative execution paths are useful mainly in two kinds of situations. The first situa- tion is when there are alternative ways to perform some actions provided in the transaction statement (e.g., in graceful degradation where a specific service can be given with degraded functionalities and each degradation is represented as an alternative). In such a case, each of the alternatives correspond to a different alternative execution path in the transaction statement. If one alternative cannot be completed (e.g., due to some error, exception or a nonfulfillment of a programmer defined condition) re-execution of the transaction statement using another alternative can be performed by rolling back the effects of the uncompleted alternative. The second situation where alternative execution paths are useful is specula- tive execution. If a thread is required to execute one task among a bunch of speculative tasks and needs to switch between one task to the other upon misspeculation, alterna- tive execution paths propose a natural way to provide this behavior. The transactional nature of alternative execution paths matches the requirements speculative task execution upon misspeculation detection: when a misspeculation is detected the effect of the current speculative task is to be rolled back before executing another speculative task.
The syntax for alternative execution paths introduces two new keywords to the language; either and or. Each of the keywords express different code blocks in which an alternative is specified. The block starting with the either keyword corresponds to the very first alternative. Each of the code blocks starting with an or keyword corresponds to one of the alternatives that are after the first alternative. The syntax of alternative execution path language construct is presented in Figure5.1.
5.4.2.2 Transactional control keywords
The Java language extension introduces transactional control keywords to give the pro- grammer control on transaction execution. Three new keywords are introduced for this purpose: transaction retry, transaction next, and transaction cancel.
The transaction cancel keyword (i.e., the cancel statement ) is the same as in the C++ specification (see in SectionC.5.2) and is used to abort a transaction statement (i.e., cancel all the effects of the transaction statement) upon a serious error where the software should stop execution immediately. Other keywords give more control to the programmer in determining the control flow of a transaction. transaction retry aborts the trans- action statement and re-executes it from the beginning. It is useful in handling temporarily raised exceptions or situations that are generated due to temporary conditions such as data
1 // Statements preceding the transaction statement 2 ...
3 transaction{ // transaction statement
4 ... //*** Code Region A ***//
5 either{ // Code for the 1st alternative
6 //*** Code Region B ***//
7 }
8 or{ // Code for the 2nd alternative
9 //*** Code Region C ***//
10 }
11 ...
12 or{ // Code for the (n)th alternative
13
14 }
15 ... 16 }
17 // Statements following the transaction statement
18 ... //*** Code Region D ***//
Figure 5.1: The syntax of the alternative execution path construct. The construct is composed of the either and or blocks (lines5-14).
races. The transaction next is similar to transaction retry but re-executes the transaction statement with the next alternative execution path. It is mainly useful within alternative execution paths especially if used for the purpose of graceful degradation or speculative execution.
These keywords are meaningful only in transaction statements, but their semantics inside or outside an alternative execution path may have slight differences. The semantics of each of the keywords according to their location in a transaction statement are described in Table 5.1.
To concretize the behavior associated to each the keyword, example usage of the key- words over the code regions marked on Figure 5.1 is shown by Table 5.2.
5.4.2.3 Exceptional control flow constructs
The usual mechanism to control the flow of an application that raised an exception is to use a try-catch block. With the use of transactions this mechanism does not change. The specification, however, defines the way a transaction throws an exception and proposes two types of exceptional throw behavior in transactions (exactly as in Section C.5.3 of the C++ specification): commit-and-throw and abort-and-throw. Both behaviors cause a transaction to throw the desired exception. However, the behaviors differ in the visibility
Keyword Only in transaction state- ment
In alternative execution path
transaction retry Rollback and re-execution of the transaction statement
Rollback and re-execution of the transaction statement us- ing the same alternative exe- cution path
transaction next Rollback and passing of the control to code following the transaction statement
Rollback and re-execution of the transaction statement us- ing the next alternative execu- tion path1
transaction cancel Rollback and passing of the control to code following the transaction statement
Rollback and passing of the control to code following the transaction statement
Table 5.1: The semantics of transactional control flow keywords proposed by our Java language extension according to their location in a transaction statement.
Keyword Behavior upon keyword ex- ecution in region A
Behavior upon keyword ex- ecution in region B
transaction retry Rollback and re-execute re- gion A
Rollback and execute code in region A and then B
transaction next Rollback and execute code in region D
Rollback and execute code in region A and then C
transaction cancel Rollback and execute code in region D
Rollback and execute code in region D
Table 5.2: Example illustrating the semantics of transactional control flow keywords using the code sample in Figure5.1.
of the effects of the transaction when the exception is thrown out of the transaction. With commit-and-throw behavior the effects of the transaction up to the point where the exception is raised are made visible to other threads with a commit before throwing the exception. In other words, commit-and-throw allows partial execution of transactions. The abort-and-throw behavior, however, rolls back all the effects of the transaction and only then throws the exception.
1The selection of the next alternative is done in a round-robin manner, i.e., if the transaction next
keyword appear in the last or block (i.e., the very last alternative), in the next re-execution of the transaction block, the very first alternative enclosed in the either block will be chosen to be executed.
Since commit-and-throw behavior allows the partial effects of a transaction to be visible to other threads at the time an exception is raised, the atomicity guarantee of the transac- tion will be violated upon an exception. Abort-and-throw behavior avoids such a problem by throwing the exception only after aborting the transaction. However, since with abort- and-throw the exception is thrown after the transaction is aborted, the exception object cannot carry information about the actions performed in the transaction and hence excep- tions that can be thrown inside a transaction are limited: only a single type of exception, CancelException, can be raised for abort-and-throw semantics. The programmer, how- ever, can give the class of a valid exception class as a parameter to the CancelException as a means to convey the reason of the exception outside the transaction.
The commit-and-throw behavior is provided by the existing Java throw statement (as in Section C.5.3 of the C++ specification), hence the syntax for commit-and-throw is simply:
throw throw-expression
To specify the abort-and-throw behavior, the transaction cancel keyword should be prepended to the existing Java throw statement. However, since only CancelException can be thrown with abort-and-throw its syntax becomes:
transaction cancel throw CancelException(ExceptionClass) Apart from the exception throw behavior, transaction statements do not possess any exception specification in the Java language specification as opposed to C++ specification (see Section C.5.3).