Transition rules for JavaT - JVM

The initial state of JavaT is de_ned as for JavaE , but started with a single thread, namely the runnable, active, current thread. Execution of the machine execJavaThread, into which execJava is embedded, continues until there are no more runnable threads. We _rst de_ne JavaT then execJavaThread and _nally the rules for starting, interrupting, notifying, and putting threads to waiting.

The additional rules for JavaT de_ne the semantics for the new synchronization statement and for the extension of the rules for exiting an initialization method or

for exiting the code of a thread. execJavaT = execJavaStmT

The rules for execJavaStmT in Fig. below start the execution of a synchronized statement by passing the control to the evaluation of the synchronization expression.

Once the synchronization expression has been evaluated, execJavaStmT attempts to grab the lock of the object denoted by the target reference, provided it is not null . If it is null , a NullPointerException is thrown.

Otherwise execJavaStmT checks whether the current thread already holds the lock of that object. In case it does, the current thread grabs the lock once more, namely by pushing it onto the sync stack, it increments the lock counter and passes the control to the execution of the protected statement. Otherwise the current thread is put into synchronization mode (and its continuation and its synchronization object are stored), so that it now participates in the competition on getting activated by execJavaThread.

Upon normal completion of the protected statement, using the rule releaseLock, the lock which was grapped last by the thread is released, by popping it from the sync stack, the lock counter is decremented, and the control is passed up.

Execution of JavaT statements

Execution of JavaT statements

Similarly, when an abruption is detected during the execution of a synchronized statement, releaseLock passes the abruption up. For this purpose, in JavaT the de_nition of propagatesAbr is re_ned to its _nal version, including also synchronized statements into those which do not propagate abruptions.

Should the attempt to handle the abruption reaches the starting position of the code of the current thread, with an empty frame stack, the thread noti_es all the threads who are waiting for him and dies.

Except for the remaining case of a thread which abrupts an initialization method, which will be explained below, this concludes the extension of execJava by the submachine execJavaT, which de_nes the behavior of any current single thread. What remains to do is to re_ne some of the rules in the previous machines.

When creating a new thread, i.e., a member of class Thread its mode has to be initialized (to NotStarted) and its locks stack and is wait set have to be initialized to empty. Formally this comes up to extend the de_nition of new which was given in the submachine execJavaExpO of JavaO by the following new de_nition:

Similarly we have to extend the de_nition of initialization. Initialization of a class or interface in JavaT requires synchronization, since several threads may be trying simultaneously to do this initialization. If initialization by one thread is InProgress, other threads have to wait, until the initialization is done or an Error occurs. To distinguish the thread that actually initializes a class from those that wait for it, we use two dynamic functions; initThread(c) is the thread that initializes class c; initWait(c) is the set of threads waiting for the initialization of class c.

The initial state of JavaT is de_ned as for JavaE , but started with a single thread, namely the runnable, active, current thread. Execution of the machine execJavaThread, into which execJava is embedded, continues until there are no more runnable threads. We _rst de_ne JavaT then execJavaThread and _nally the rules for starting, interrupting, notifying, and putting threads to waiting.

The additional rules for JavaT de_ne the semantics for the new synchronization statement and for the extension of the rules for exiting an initialization method or

for exiting the code of a thread. execJavaT = execJavaStmT

The rules for execJavaStmT in Fig. below start the execution of a synchronized statement by passing the control to the evaluation of the synchronization expression.

Once the synchronization expression has been evaluated, execJavaStmT attempts to grab the lock of the object denoted by the target reference, provided it is not null . If it is null , a NullPointerException is thrown.

Otherwise execJavaStmT checks whether the current thread already holds the lock of that object. In case it does, the current thread grabs the lock once more, namely by pushing it onto the sync stack, it increments the lock counter and passes the control to the execution of the protected statement. Otherwise the current thread is put into synchronization mode (and its continuation and its synchronization object are stored), so that it now participates in the competition on getting activated by execJavaThread.

Upon normal completion of the protected statement, using the rule releaseLock, the lock which was grapped last by the thread is released, by popping it from the sync stack, the lock counter is decremented, and the control is passed up.

Execution of JavaT statements

Similarly, when an abruption is detected during the execution of a synchronized statement, releaseLock passes the abruption up. For this purpose, in JavaT the de_nition of propagatesAbr is re_ned to its _nal version, including also synchronized statements into those which do not propagate abruptions.

Should the attempt to handle the abruption reaches the starting position of the code of the current thread, with an empty frame stack, the thread noti_es all the threads who are waiting for him and dies.

Except for the remaining case of a thread which abrupts an initialization method, which will be explained below, this concludes the extension of execJava by the submachine execJavaT, which de_nes the behavior of any current single thread. What remains to do is to re_ne some of the rules in the previous machines.

When creating a new thread, i.e., a member of class Thread its mode has to be initialized (to NotStarted) and its locks stack and is wait set have to be initialized to empty. Formally this comes up to extend the de_nition of new which was given in the submachine execJavaExpO of JavaO by the following new de_nition:< br>

Similarly we have to extend the de_nition of initialization. Initialization of a class or interface in JavaT requires synchronization, since several threads may be trying simultaneously to do this initialization. If initialization by one thread is InProgress, other threads have to wait, until the initialization is done or an Error occurs. To distinguish the thread that actually initializes a class from those that wait for it, we use two dynamic functions; initThread(c) is the thread that initializes class c; initWait(c) is the set of threads waiting for the initialization of class c.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

JVM Topics