Changes between Version 4 and Version 5 of JavaParty/TransparentThreads


Ignore:
Timestamp:
01/17/07 10:40:50 (6 years ago)
Author:
huetter
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • JavaParty/TransparentThreads

    v4 v5  
    33Since JavaParty 1.07a 
    44 
    5 == Introduction == 
     5With transparent distributed threads, JavaParty provides unmodified Java thread semantics regarding synchronization and thread control in the distributed environment. 
    66 
    7 With transparent distributed threads, JavaParty provides unmodified Java thread semantics regarding synchronization and thread control in the distributed environment. 
    8 Transparent synchronization 
     7== Transparent synchronization == 
    98 
    109Unlike in RMI and other RPC-style middle-ware platforms, synchronization semantics in JavaParty is the transparent extension from one virtual machine to the whole distributed environment. 
    11 Synchronization reentrance 
     10 
     11=== Synchronization reentrance === 
    1212 
    1313In JavaParty, a distributed thread is allowed to re-enter an once acquired monitor no matter how many interleaving remote invocations are on the stack in between. This extends the Java thread semantic from one virtual machine to the whole distributed JavaParty environment. 
    … …  
    1515With RMI and other RPC-style middle-ware platforms, re-entering a synchronization with interleaving remote method calls causes a dead-lock of the running application thread. 
    1616 
    17 See also wiki:JavaParty/DistributedThreads and the paper "Transparent Distributed Threads for Java". 
     17See also wiki:JavaParty/DistributedThreads and the paper [http://www.ipd.uka.de/JavaParty/archives/p147.pdf "Transparent Distributed Threads for Java"]. 
    1818 
    19 == Synchronized blocks ==  
     19=== Synchronized blocks === 
    2020 
    2121Besides synchronized methods, the Java language has so called synchronized blocks that are blocks of code synchronized on an arbitrary object. The object used for synchronization has not necessarily to be the one the surrounding method belongs to. In JavaParty, synchronized blocks are supported on arbitrary objects whether they are local or remote. This is possible because KaRMI supports "Remote Monitor Access (RMA)". JavaParty uses this feature to acquire the monitor of the object on the remote node, if the argument to the synchronized block statement is detected to be remote at runtime. 
    … …  
    2323With a middle-ware platform like RMI or pure KaRMI blocks synchronized on remote objects are not possible, because the synchronization is acquired on the remote reference instead of the remote object itself. 
    2424 
    25 See also wiki:JavaParty/RMA and the paper "Transparent Distributed Threads for Java". 
     25See also wiki:JavaParty/RMA and the paper [http://www.ipd.uka.de/JavaParty/archives/p147.pdf "Transparent Distributed Threads for Java"]. 
    2626 
    2727== Transparent thread control ==  
    … …  
    3131With RMI, management of distributed threads is not possible, because interrupt signals only reach the local Java thread. If this thread is currently waiting in a remote method execution, the signal to get stuck at the local node waiting for the remote invocation to return. If the interruption is the only signal set to the thread this also causes a dead-lock. 
    3232 
    33 See also the paper "Transparent Distributed Threads for Java". 
     33See also the paper [http://www.ipd.uka.de/JavaParty/archives/p147.pdf "Transparent Distributed Threads for Java"]. 
    3434 
    3535== Identification of transparent distributed threads ==