Learning Center
Plans & pricing Sign in
Sign Out



									                 A compiler to implement LOTOS specifications
                          on distributed environments
                                                                               ¡              ¡
                     Keiichi Yasumoto , Teruo Higashino and Kenichi Taniguchi
                             Dept. of Information Processing and Management, Shiga Univ., JAPAN
                             Dept. of Information and Mathematical Sciences, Osaka Univ., JAPAN
                                   e-mail: higashino,taniguchi
                                              ¤                            ¥

         Abstract In this paper, we propose a method to implement distributed systems using the
         formal description language LOTOS. First, we give a sub-class of LOTOS for specifying
         distributed systems. In the sub-class, each system’s behavior is described as a set of inter-
         acting processes where each process is assigned to a specific node of a distributed system
         and inter-node process interaction is specified with LOTOS operators such as choice, dis-
         abling and multi-way synchronization. We propose a method to implement such a LOTOS
         specification as a set of programs which run on the corresponding nodes cooperating with
         each other by exchanging messages. In the proposed method, we transform processes as-
         signed to a node into a multi-threaded executable program, and implement LOTOS operators
         specified among processes on distributed nodes with total-order broadcast communication.
         We have developed a LOTOS compiler based on the proposed method. Some experimental
         results show that programs generated from distributed systems’ specifications can be used
         as prototypes for practical use or for performance evaluation/analysis.

Keywords: LOTOS, multi-way synchronization, distributed implementation, compiler, formal descrip-
tion techniques, multi-thread

1    Introduction
In order to reduce ambiguity and mistakes in developing large-scale and/or complicated systems, formal
description techniques (FDTs) are getting increasingly important. Among FDTs, the formal specification
language LOTOS [9, 13] was standardized within ISO in 1989.
    Since LOTOS has powerful operators such as parallel with synchronization and disabling, we can
effectively specify a distributed system consisting of multiple nodes by composing each node’s behavior
as a process and by composing the entire system with LOTOS operators on top of those processes. For
example, imagine a system consisting of four nodes,          , and where messages sent from C via
gate must be received at either or , messages from via gate must be received at both and
                                                 ¦          ©                                         ¦
© , and every event occurred at       must disable
                                                        and . We can easily specify such interaction
among nodes in LOTOS as follows (             are the parallel operator with synchronization gates and the
                                                      # "§ !  
disabling operator, respectively):

                                      ' &$
                                      (%%$             2 0
                                                       31&               2 7
                                                                         98&        @
                                             !)           §
                                                             !654          #
    Like this, LOTOS is suitable to describe distributed systems in an abstract way. Then the subsequent
goal should be to automatically generate executable programs as prototypes.
    Several implementation techniques and compilers for LOTOS specifications have been proposed so
far [4, 6, 15, 18, 21, 23]. However, since they mainly aim at simulations/performance analysis of sys-
tems, they do not generate programs which treat interaction among distributed nodes. However, for the
rapid prototyping of distributed systems, it is needed to implement LOTOS operators over distributed
nodes. In LOTOS, the synchronization operator can be specified among multiple processes so that they
execute events on the specified gates synchronously (called multi-way synchronization). Simultaneous
use of the synchronization and choice operators (as well as the disabling operator and the parallel oper-
ator without synchronization gates) will lead to situations where several synchronization process groups
                                                                                                            2            &
                                                                                                                         B$   2
become executable but only one of them is permitted for execution (e.g.,                                  ).
                                                                                           §   §   C  
                                                                                          )!4 IH GF!4 E ) D6 ! 
When such processes are located on distributed nodes, they must communicate with each other via the
underlying network to make a consensus (i.e., to decide a process group to be executed). Execution of
each synchronization needs its participant processes to be ready to execute the corresponding events.
Therefore, to reach a consensus, (1) each process must broadcast its information about its ready events
to the other processes it may synchronize with, (2) it must identify ready candidates of synchronization
process groups, and then (3) it must decide one of them in a consistent policy so that all processes do the
same decision.
    Two approaches can be considered in developing algorithms which solve the above problem in multi-
way synchronization: (A) using general asynchronous peer-to-peer communication and (B) using broad-
cast communication.
    In approach (A), several techniques have been proposed for a restricted class of LOTOS [2, 3, 17].
In general, processes are not always ready for each synchronization execution. So, in many cases, it may
be better to decide a process group whose members become ready earlier than other groups. However,
since the existing algorithms of [2, 3, 17] use the peer-to-peer asynchronous communication, when a
process broadcasts a series of messages, the messages may be received in different order among nodes.
This delays each node to make a decision until receiving all messages from mutually exclusive process
                                                         2 Q
                                                         TS R$ P               2 U Q
                                                                               3Q VR$ P     2 Q aYW Q
                                                                                            dcb`XR$ P
groups. Consequently, each algorithm requires
                                        Q                   [2],           [3] or              [17] message
exchanges to make a consensus where is the number of all related processes (nodes).
    In order to obtain more efficient implementations, approach (B) using broadcast communication
may be reasonable due to the following reasons: (1) Nowadays, many hosts are connected to local
area networks (LANs) which use broadcast channels (e.g., Ethernet). (2) Owing to the property of
such networks, each broadcast message costs as much as a message exchanged between two hosts, and
messages are received in the same order among all nodes. Although there are no complete reliability
in message broadcasting on general broadcast channels, there have been proposed several techniques
to provide reliable broadcast communication on such networks [12, 14, 16]. On LAN environments, a
proxy-based technique is also applicable at a cheaper cost [25].
    In this paper, we propose an efficient implementation method for distributed systems described in a
subclass of LOTOS on the networks where total-order broadcast is available.
    In the proposed subclass of LOTOS, we can compose a distributed system of multiple concurrent
processes. Its main characteristics are as follows: (1) we can specify for each process on what node the
process is invoked; (2) the choice, parallel, sequential and the disabling operators can be specified among

                                       Table 1: Synchronization condition.
            f&          g h&
                                      condition                            result
          e pAai          i
                      gqpAa     2g p$t s r w 2e p$t s
                                 !yB6u5x9vqBvu5r        value matching
         e pAa        ƒ €
                    …†„‚Aa     2 …$ –• s “ ’  ˆ 2e p$t s
                                                        value passing
                                                            2e p$t s r ™
        iƒ g€ …ƒ €
        †h‚ha †f‚Aa                     i w
                                        kj…                 value generation
                                                           2 …$ –• s “ ’  ˆ o n o n m ™
                                                           !`˜—u”u‡‘V†dm †delg 
                                                                       ,                     §
      (u tsr q
       vvF†Gp  is the normal form of the expression     ,
                                                      |u9t |        is the domain of the sort .
                                                                                      u s zq yx
                                                                                      G}|A{†¨5†w t       is the value
      input at gate )

processes on different nodes; and (3) a process at a node can dynamically perform process invocations
for other nodes.
    The behavior expression of each process is composed of (i) environment events (and internal events)
which are executed within the node, (ii) synchronization events which synchronize among processes on
different nodes and (iii) process instantiations as well as primal LOTOS operators (such as action prefix,
choice, parallel, enabling and disabling).
    We implement such a LOTOS specification as a set of programs which run in parallel on the corre-
sponding nodes cooperating with each other by exchanging messages (see Fig. 3). In the proposed tech-
nique, processes on different nodes independently broadcast requests for their synchronization events
ready to be executed, and then each node selects the first enabled synchronization group from several
exclusive ones according to temporal order of the received messages. Since our subclass allows hier-
archical choice/disabling and multi-way synchronization among processes in addition to their dynamic
invocations for different nodes, each node’s program needs to know the current relation among those pro-
cesses. To keep the latest relation in programs, when each process is invoked or terminated at a certain
node, a message for invocation/termination is broadcast with the location of the process in the current
syntax tree to update the relation in all other nodes.
    In the following section 2, we give a definition of a subclass of LOTOS for distributed systems.
In sections 3 and 4, we give implementation techniques for the interaction among nodes, and for the
internal behavior of nodes, respectively. In sections 5 and 6, applications and evaluation of our compiler
are presented. Finally, section 7 concludes the paper.

2     Description technique for distributed systems in LOTOS
In this section, we present and outline the LOTOS language, and then propose our subclass of LOTOS
for describing distributed systems.

2.1    LOTOS
To specify the temporal order of events, we use several operators in LOTOS such as action prefix (which
combines events with ‘;’ in sequential order), choice ([]), parallel, sequential and disabling between any
two sub-behavior expressions.
    If we specify the parallel operator with synchronization gates (       , called the synchronization op-
erator, hereafter) between two behavior expressions, their events on the specified gates (and exit)           
must be executed in synchronization with each other, while other events not included in are executed  

                                                   Table 2: Proposed subclass of LOTOS

                                                                                              € Œ Œ €ˆ €Šˆ €† 
                    € †  € † ˆ € ˆ € † ˆ € ˆ‘ ˆ € † ˆ € ˆ € † ˆ € † Œ ›‘ š ™– ˜ — •” ”  ˆ € †  € †  €
                    AhŸŒA1’hƒ†…ˆh˜’h…†`fŸ†žh˜’h…†ƒˆƒˆ¨h˜‰hœœRGTBjB–‚b)“ 1’hR‘ ADƒ„…Žh†
                                                       ‘ ‘ « š ˆ ª ˆ¨§ – ¤ ” ˆ £¢ ‘ ‘  š ˆ € † Œ Œ € †
                                                       ‰¡ —fŸ†E¬fvbƒ£©`)¦• ¥b‡˜ GvT‰¡ —fŸ†Žf’h ‰Xh˜ˆ
                     ˆ‘ ˆ € Š ˆ € ˆ € Š ˆ € Š Œ ›‘ š ™ – ˜ — • ” ”  ˆ €  € Š ˆ € Š³ ˜ ¦¨± ° ˆ ¦ ™ – ˆ š ”¨§  €
                 €­Š `fƒ†…¨f‹’­Š ƒˆ…ˆ­‹‰fµœRGTBqB–‚b)“ 1´fŸŠ‘ ¨­h´f—f‚®”—²˜‹¯®¨TBf ‚RRh…„ƒ­fŠ
€fŠq®˜¦T%§h‚”®—¨‚—²B!AŽ¹¥¥¸·AB}–‹‰fq®˜I‰¥®¤b˜q‰¡ —fŸ† « ‹‰fI9Xf‹‰fŸŒf‹‰fŠ ƒˆ¨f‹ˆ
        ª ˜ ¦ — º •± – ¤ – • — ¢ ¨ • ˆ € Š ¦ † – ¦ ¶ ˆ ‘ ‘ š ˆ € Š Œ Œ € Š ˆ € Š  € Š ˆ € ˆ € Š
                                               ¦ˆ ‘ š ™ – ˜ — • ” ”  ¨§¦ Š ¿ ½ –¨ — » ˆ ¨§¦ Š ¿ ½ –¨ — » ˆ –¨ — »  ˜ ¦¨±
                                               )"bTBqB–‚b)“ ­`)f3!¾—G‹`)f3!¾—Ghœ—!¼…„ƒ‚®”—²˜°
                                                                                             ¨§¦ Š ¿ ½ ¿ ½ˆ ¿ ½  ¨§¦ Š ¿
                                                                                                  š ™  ˆ ¨º”§ º — ·À  ¿
                                                                                                   TB– Gf‚‚`Ž ¥¥FÁƒ„ƒ‘!½
                                                                                                        †Ã –¨ — » ˆ –¨ — » 
                                                                                                        ²5RGfl—G¼ƒ„… †
               any expression defined in the subclass of ACT ONE (see Sect.4.4)
                                                                                                                               š™
                                                                                                             ڙ– ˆ š™– 
(Here, is an internal event.
                                      «š   is a process instantiation for the same node, and
                                                                                                ª ˆ¨§ – ¤” ˆ £¢
                                                                                                b…£%`)¦• ¥‚u˜ GF¬š     for other nodes)

independently (if        , we denote it by called the interleaving operator). The synchronization op-
                                                                                                        2                   $
erators can be specified hierarchically over multiple expressions like                         , which forms     Ç © G5  S © G)4 E‡l©
                                                                                                                                  §  Æ
multi-way synchronization. In this example, events on gate must synchronize among                      S ©5!ÆÈ©
                                                                                                    and ,   §                                         Ç
while events on can synchronize between
                                                   and     or between   Æ
                                                                         D©and    S ©
                                                                                   . In general, we define                      Ç V© a ¯©   Æ
that a multi-way synchronization specified among some processes on a gate can be executed only if (i)
any pair of those processes are ready to execute their events on , (ii) the pair of the events satisfies the
synchronization condition in Table 1, and (iii) the guard expressions (predicates) of the events hold after
the value passing by the synchronization.
    The disabling operator (                 S É# 4µ©
                                       ) enables the sub-behavior expression
                                               © Æ                              to interrupt the execution         S ©
of  Æ ©by the execution of an event in                     S ©
                                           . In the sequential composition (            ), the sub-behavior   S ÅÊ# Æ ©
                                                                                                                © #
expression        S ©
                can be executed when        finishes successfully with the exit operator (we call ‘
                                                          ÆÊ©                                          ’ the                                   # Ê#
enabling operator, hereafter). In a LOTOS specification, we can replace any sub-behavior expression
                                           2 p 
                                           IB$   9Ë                                                                                             p
by a process instantiation          (here, we can give the actual gate list and data value list to be          
used in the process instance). By this facility, we can compose the whole behavior expression as a set of
structured processes (See [9, 13] for details of LOTOS).

2.2           A subclass of LOTOS for specifying distributed systems
      ÓÒÐÏY ѧ ÐÏY QÍ
      "uŽdQ §EÑÑ5!Æ uŽdGÎw Ì
Let                           be the set of all nodes in a distributed system. In order to treat distributed
systems explicitly in LOTOS, we add to our subclass a facility of where each LOTOS process is invoked.
Fig. 1 shows a graphical representation of a LOTOS specification consisting of five processes P, Q, R, S
and T among which some LOTOS operators are specified. In this figure, processes P and Q are assigned
to node1 and node2, respectively.
    In the proposed subclass, the choice, parallel (synchronization and interleaving), disabling and en-
abling operators can be specified among processes over nodes. We assume that several nodes share some
gates for the synchronization operators. The events executed on such gates are called synchronization
events. For example, in Fig. 1, gate is shared between node1 and node3, and between node2 and
node3. Also, we assume that each node has a set of local gates through which processes on the node
interact with the environment of the node. The events on such gates are called environment events. Con-
                            gÐÏY                                                                    g
sequently, each         Ì ˆ "TdQ
                             has a set of shared gates denoted by       and a set of local gates denoted by
                          LOTOS Spec.

                                                        |[a,b]|                            |||


                            P[a]                 Q[b]                 R[a,b,c]   S[...]              T[d]

                                node1             node2                  node3                   node4


                                Figure 1: Node assignment in a LOTOS specification

        Ä w Ö
         אg Ô 3g Õ g Õ             Ø     w
                                g Ô yg Õ g ¦                                                                 gÐÏY
    (              must hold). Let                  be the set of all gates available in       .
     We give the syntax of the proposed subclass of LOTOS in Table 2. We denote the invocation of
g Ð"ώY3Q
a process on Ë          by
                                        ¬Ù  g uŽdQ  %$ Ë
                                        2 ÐÏY Ù
                                           . The node assignment part may be omitted if the invocation is
applied to the same node.
     With the subclass, a distributed system can be described as follows. First, the initial behavior expres-
sion is described with the production rule       in Table 2 (called global behavior expression) so that only
the choice, parallel, disabling and enabling operators are specified among LOTOS processes which may
be assigned to different nodes. Second, each process is described with either             or      (called local
                                                                                                         ©        © Õ
behavior expression). This means that each process assigned to a node in turn invokes other processes
over nodes like the initial behavior expression or devotes itself to the internal behavior of the node (i.e.,
by executing environment events and synchronization events of the node). The internal behavior of each
b"Ž3Q   is described with       © Õ
                                 where primal LOTOS operators including action-prefix, choice, parallel,
                                                                                     g ¦
disabling and enabling operators are specified among events of               and process instantiations for the
same node.
     As explained above, there is an explicit hierarchy in the subclass:       for the interaction among pro-
cesses over nodes and     © Õfor the internal behavior of each node. The main advantages of this approach
are: (1) the whole system can be composed easily and intuitively by specifying LOTOS operators (e.g.,
multi-way synchronization) among processes over nodes; and (2) implementation will become simpler
(i.e., we can concentrate on the implementation of process interaction over nodes) because the internal
behavior of each node can be implemented with the existing LOTOS compilers.
     The expressive power of the subclass is demonstrated with some examples in Sect. 5.

General restrictions
In effect, we do not put any restriction on the forms of behavior expressions beyond what is specified
within Table 2. However, in implementation, the following physical restriction associated with infinite
behavior may arise.

                                                             P[a,b] |[a,b]| (Q[b,c] |[c]| R[c,a])
                              process P                                                                               process Q

                                             a;... [] b;...              synchronize                 b;... [] c;...
                                                                          via gate ‘b’

                                          synchronize                       c;... [] a;...          synchronize
                                           via gate ‘a’                                             via gate ‘c’

                                                                           process R

                                         Figure 2: Mutually exclusive synchronizations

     Hereafter, let     and represent processes. We do not treat recursive process instantiations pro-
                         5§          H                                                                          w‰&
                                                                                                                  ƒ               &        Í
                                                                                                                                           ׈                       Ó
ducing infinite number of processes and/or process parameters (e.g.,                                       ,                 Û
                                                                                                                            ÜC        Û
                                                                                                                                      q§            §
                                                                                                                                                # 4§ G  46 
$ Q ÐÏàÞ ƒ
 ¼và "b‡ßwÝ&                        ƒ 2 $ 2
                                   Ewµ8`¯& ¯&                  9R$
                                                               2              22 $ á$
                                                                               %8`AB¯&                    2 
                        G) hC                         C            #, etc). Although executable pro-
                                                                      Ê#                       H #
grams can be obtained from such specifications, they will soon consume all of available memory area.
However, we treat recursive process instantiations where the number of process instantiations is bounded
       ‡×f $
       åä ã      wd8`¯& &
                   ƒ 2 $       wx&
                                  ƒ                                             2 ä è $
(e.g.,        Û
             dC      ,    # #
                            ÊÁC                               ), etc).
                                                                     # æ
     In the standard LOTOS, we can use the following operators in addition to the operators in Table 2:
par, choice, parameterized exit and accept. We do not treat these operators. Also, the value generation in
multi-way synchronization is not supported since it may be undecidable to generate a solution to satisfy
all guard expressions of synchronization events.

2.3     Target network and assumption
When synchronization operators are specified among processes and each process includes choice of
events on different gates, several mutually exclusive synchronization process groups (hereafter, we
merely call each group a synchronization) may become executable simultaneously (see Fig. 2).
     In order to implement such mutually exclusive synchronizations correctly, processes located on dif-
ferent nodes need to exchange messages with each other to make a consensus for selecting a synchro-
nization. If we implement the mechanism on a general network where the broadcast messages may
be received in different order among nodes, we cannot take the strategy of selecting the first enabled
synchronization based on temporal order of the received messages.
     Unlike the algorithms proposed in [2, 3, 17], in our subclass of LOTOS, we allow to specify the
choice, parallel, enabling and disabling operators with process instantiations over nodes. Thus, the
synchronization relation among processes can change dynamically, resulting in more message exchanges
to know possible combinations of synchronizing processes.
     According to the above discussion, we focus on broadcast networks which have the following prop-
erties, and develop an implementation algorithm specialized for such networks.

  (1) each message is received at all nodes in a distributed system by a broadcast.

  (2) all messages are received at each node without failure (i.e., without losses and duplications) and
      stored in the message buffer of the node.

  (3) broadcast messages are received in the same order among all nodes.

      In Sect. 3.3, we will discuss how to realize the above network on practical environments.

                                                                                                                                                               … q † x s  f ˆ q q † s … … q ‚  v y x vt r q i g g
                                                                                                                                                               h‰p‰)))‡hh£h„ƒwt H€pg wus p)phf
                                                                                                                         ûù ÷ö
                                                                                                                       Ÿü!úø B©õ
                                       e YGdG V Yc Y XV UTSRQPIG E B C B
                                        3P `#`WP # aXb `G W##&¨¨HF)D¨A
                                                   mmm                      m dp & mjn
                                                                                l o
                                                           £££¤ )¡                                            l j
                                                                                                               “n £q                          ´³                               ´³                    ´³                                        ´³
                                   ™ 
                                  Ÿ“ —u ª © ¨ §                      ” ’               … ƒ
                                                                   ‹ w ‹ w ‰  ‡ † w | u
                                 wužw˜ £u–œ š› « (wwu ¥¦ Ž w• &wŒ“ uŠ‘ hˆwdw~„ }u{‚ € z (wwu rs          yxvt                       µ µ µ ¹µ ¸ w¶ ³ µ
                                                                                                                                                  · ¹³                 µ µ µ ¹µ ¸ w¶ ³ µ
                                                                                                                                                                                   ·          µ µ µ ¹µ ¸ u¶ ³ µ
                                                                                                                                                                                                         ·                               µ µ µ ¹µ ¸ u¶ ³ µ
                                                                                             ©§ ¥ ¢  þ
                                                                                            ¨¦ £¤ £¡ÿ ‚ý                                                                               ¹³                       ¹³                ¹³
                                     ' (  &¦ ¨! 0  £ý  )(  &¦ # !  ý 
                                        ' ¤ $"  % ' % $"   
                                                        ¥4 38 932 8 9¥ &3 6§ ! © )¨&¡ÿ !4
                                                       @ 6 4¥ 6 4 87                            þ 1 § 35¥ ÿ þþ 1
                                                                                                                                            ±            ¬                        ­ p¬    ¯          ® £¬       °                                         ²
                                                                                                                                        vR—îóïô R`®ìëò —Fìñí —®ðë êì         — ’• ’
                                                                                                                                                                             #– ¨“” “‘
                                                                                                                                                                                                    #– ¨“” “‘
                                                                                                                                                                                                    — ’• ’
                                                                                                                                                                                                                                          ¨– &`” “‘
                                                                                                                                                                                                                                          — ’• ’

                                                           Figure 3: Basic concept to implement a distributed system

                                                                                Table 3: An example of LOTOS specification

spec.:= ( P
                        ª ˆ¼ – ¤” ˆ £ ˆ‘ à ˆ ª ˆ» – ¤” ˆ £            ª ˆº –¤” ˆ£
                        b…£²½¥‚u˜ !F¢ `6®“"— žúbƒ£6F¥‚u˜ GF¢ bƒ£)¡¥‚u˜ Gv¢
                         [] Q                     R              )
             ŸŒ             T               )
                                                ª ˆ¾–¤” ˆ£ ˆ ª –¤” ˆ£
                                                 bƒ£©¿¥‚u˜ Gv¢ ƒˆ…ˆúb…£ˆ º ¥b‡˜ Gv¢
where P:= (a!3;exit)
                            bƒ£ˆ ¼ ¥‚u˜ !F¢ …ˆúbƒ£ˆ » ¥b‡˜ Gv¢
                            ª –¤” ˆ£ ˆ ª –¤” ˆ£
                          ( P1                 P2            )
                                                                    Œ ‰Œ
     Q[b]:= b;Q
     R[a,b,c]:= a?x:nat[x gt 0]; R [] b;R [] c;R
     S[...]:= (S1 S2 ) [] S3
     T[d]:= d;stop
(process declarations for P1, P2, S1, S2 and S3, and parameters for process instantiations are omitted.)

2.4                Basic concept for implementation
In our implementation method, we generate a set of programs 1 for the corresponding nodes in a dis-
tributed system from a given LOTOS specification. The generated programs work as specified in the
specification, cooperating with each other (Fig. 3).
    For example, four programs for           ,        ,         and          are generated from the LOTOS
                                                                                                           ÐÏY ÐÏY ÐÏY
                                                                                                         Ç "ŽdQ S "Ž3Q Æ "ŽdQ                                                    h"Ž3Q
                                                                                                                                                                                 ÀÐ Ï Y
                                                                                                                                                                                                                                Í         Í Ó                 Í Ó   Ó
specification in Table 3, and those programs can execute the process instantiations P,S , Q,P1 , R,P2
             Ó Í
and T , respectively. First, those programs invoke the processes in the initial behavior expression. In
the program of
                                    Æ "Ž3Q
                      , processes P and S are invoked.
    We use the term inter-process relation to indicate LOTOS operators and their structure specified
among all processes invoked in the current behavior expression. The initial inter-process relation corre-
sponds to the area within the dotted rectangle in Fig. 4(i). In the relation, two exclusive synchronizations
   and are executable for the combinations (P, R) and (Q, R), respectively. Several disabling events
may also be executed in S and T.
    The inter-process relation changes dynamically when new processes are invoked and/or existing
processes are terminated. In the example of Table 3, when a synchronization            of (P, R) is executed,                                                                                                          
process Q must be terminated and new processes P1 and P2 are supposed to be invoked. After that, the
relation changes from (i) to (ii) in Fig. 4.
    Therefore, we need to make each node hold the latest inter-process relation in order to keep temporal
             Hereafter, we use the term ‘program’ as executable code

                       (i)                   Inter−process relation

                                                           [>                                                                            [>

                                             |[a,b]|                    |||                                               |[a,b]|                     |||
                                                                                         event ‘a!3’
                                    []                                                   is executed               ||

                                         Â   Q         R
                                                                Ã   S
                                                                                 Ä   T                                                        Ã              Ä
                                                                                                              P1         P2         R’            S              T

                                    Figure 4: Inter-process relation and its dynamic change

order of events among processes.
    Let us denote that derivable events are the events which each process is ready to execute (environment
events and synchronization events).
    In our implementation algorithm, each process calculates its derivable events based on the technique
explained in Sect. 4 and broadcasts a request message asking for their execution. Each node selects a syn-
chronization (or an event) among several exclusive ones based on the latest inter-process relation shared
among all nodes and temporal order of the received messages in its local buffer so that the synchroniza-
tion constructed by earlier messages is prior to the others. For example, when the request messages are
broadcast in order of
2 C $          Ê& H $
                 2 §             5§ &
                            and in Fig. 2, the synchronization of
                                 C               H                           is selected prior to other ones
                                                                                                                        2 5§ B$
                                                                                                                          C &
  H§    and        .

3      Implementation of the interaction among nodes
3.1       Algorithm
First of all, we assume that messages broadcast from all nodes are received and stored automatically in
the message buffer (FIFO queue) of each node and that the buffer capacity is sufficient to keep all of
    In the program of each node, we allocate a working space called control area to keep the initial
inter-process relation among nodes.
    We compose each node’s program of several behavior parts and a message handler (they are imple-
mented as multi-threaded code). In each behavior part, a process assigned to the node is implemented. It
                                                                                           Ó ¡5%DÆD‚9 Í
calculates the set of derivable events of the process               (the details will be explained in Sect. 4)
                                                                                             Ç  §Å Å Å §Æ
and broadcasts a request message for the set. The message handler selects a synchronization (or an event)
to be executed from the latest inter-process relation and temporal order of the received messages in the
buffer. The corresponding behavior part executes the selected event after the message handler permits its
                                                                              Æ "Ž3Q
execution. Fig. 5 shows the organization of          ’s program in the example of Table 3.
    In the algorithm, we use the following two types of messages exchanged among processes:
                            2 Ï Ë Í… QÐ ÌÐ$Ë É
                             uGà ©§ pAB(u%¬DÐ ÊÈ
                                    for requesting execution of some events
                             Ï Ë Ï $…Í Q
      2†Ð"ÏTYdQ § Þ¥… fË%§ Gà ©§ Ð D Q Ë ¥BÎ6à È          for requesting a process instantiation
                                         FÐ É
                                         Ë                                               Í … QÐ Ì
    Each      message has two parameters where Gà Ë
                                               Ï            denotes the set of derivable events of a process,
and      denotes the unique identifier of the process to find its derivation path (the path from the root in
the inter-process relation to the corresponding leaf position of the process). Each        message has four
                                                                                                                                                      …Í Q

                                         message handler
                                                   message buffer                                     control area
                                                         req({a},P)                                                     [>
                                                         req({b},Q)                              |[a,b]|
                                                    Õ    inst(P1,...)
                                                    Õ    inst(P2,...)                       []

                                                                                                  Ò   Q            R
                                                                                                                              Ó   S
                                                                                                                                                  Ô   T

                                         behavior part for process P                   behavior part for process S

                                                                                                                         []       control
                                                    >> (P1 [] P2)                            Ó                      Ó                  Ó
                                                                                                 S1                     S2                 S3
                                                         Ñ                                                     Ñ   threads

                                           Ö   boradcasting messages for sync. requests and process instantiations

                                         Figure 5: Organization of each node’s program

                         Ð D Q Ë                                                                                                          Ï
                                                                                                                                           bà Ë
    parameters where       Ï     specifies the process name to be invoked,         represents its unique identifier
                  DÐ É
                  Ë                      Þ 
                                         ¥… fË
    to be used in       messages,        denotes its derivation path for specifying in what context it is invoked
    (e.g., the derivation path of process P2 in Fig. 4 (ii) can be represented by “ -left-
        "Ž3Q                                                                                       -left- -right”),                                       #    §
    and        indicates where it is invoked.
        In our algorithm, it is essential (1) to correctly implement the interaction among processes and (2) to
    keep the inter-process relation consistently among all nodes.

    How to implement operators specified among processes
    The types of the interaction are choice, disabling and synchronization among processes. Simultaneous
    use of these operators may produce several mutually exclusive synchronizations. In that case, the same
    synchronization has to be selected among all nodes.
        The choice and disabling operators can be implemented fairly with the following policy: if a process
Ë     wants to execute its derivable events, broadcasts a request message for those events with the process
        Gà Ë
        Ï                                                             Ë
    ID ‘ ’. When each node’s message handler processes the message from its buffer, it examines its
    derivation path from ’s position (leaf) to the root in the control area and checks at each choice/disabling
    operator whether or not different side of the behavior expression has already been selected or an interrup-
    tion has already occurred. Only when the handler detects that any different side has not been selected, it
    accepts the message, and immediately updates the derivation path (a flag, e.g., left/right, is written in the
    variable corresponding to ‘ ’ or ‘ ’) After that, executes one of its derivable events at random. In this
                                                  #                         Ë
    policy, the process which broadcast a request message earliest of all is selected and executes its event.           2 × Ï Ë Ó ÏÍ$Ë
                                                                                                                        hØbà %§ "¬BŽFÐ É                                2 Ù Ï Ë Ó Í$Ë
                                                                                                                                                                        ˜Úbà %§ ‡0Ái  BŽFÐ
        In the example of Table 3, suppose that the request messages                      and                                                                       É
    from processes T and P have been broadcast in this order. The message handler of each node stores
    a flag in the variable corresponding to       when it processes        #         . When the later message  É                 Ï Ë Ó ÏÍ$Ë
                                                                                                                             2 × Gà ©§ "¬BŽFÐ

É    2 Ù Ï Ë Ó Í$Ë
     ˜ÛGà ©§ ¬0Ái  %¬DÐ
                        is processed, the message handler detects the occurrence of interruption on the deriva-
                                   É   2 Ù Ï Ë Ó Í$Ë
                                       ˜€Gà ©§ ¬dÁi  %¬FÐ
    tion path of P. Then,                     is rejected and process P is terminated.
        The synchronization operator is implemented as follows: when each message handler processes a
    request message        for synchronization events, the handler stores the information about the synchro-
    nization events in the variable corresponding to           operator which is the nearest to the leaf on the
    derivation path of ’s sender. If the handler finds appropriate synchronization peers at the variable of
       , it applies the same operation to the upper variables of
    !q                                                                   operators with the new event values
    after matching the synchronization condition. If there is no upper            in the derivation path, then the
                                                                                                       G Ü  
    handler permits the events to be executed.
        When the derivation path of a process includes only operators without interaction with other pro-
    cesses (i.e., the path consists of the interleaving operators and left-side operands of the disabling oper-
    ators), its derivable events need not be broadcast. In our implementation, when each process checks its
    derivation path and it knows that its derivable events do not need any interaction, it executes its events
    independently of others.

    How to keep inter-process relation
    The inter-process relation changes when (i) choice and/or disabling are applied to their associated pro-
    cesses or (ii) when a process terminates or is invoked.
         In case (i), when each node finishes calculation of what processes have obtained permission to exe-
    cute an event by the above algorithm, its message handler stores, in the variables along derivation paths
    of those processes, flags indicating that they have been selected. Thus the relation is updated among
    all nodes. Once choice or disabling is done, variables corresponding to choice/disabling operators may
    become unnecessary. Such unnecessary variables are removed from the control area when the messages
    from all unselected/disabled processes have been processed and the processes have been terminated.
         In case (ii), when a process instantiation becomes executable in a process on a node, the message
    handler of the node calculates the derivation path of the process instantiation and broadcasts a request
    message for the process instantiation with its derivation path. When the message handler at each node
    processes the message, it extends its control area with the derivation path in the message, and then it
    invokes the process if it is requested for the node. On the other hand, when a process executes the
                                                  2 Ï Ë …à Ð$ Ë
                                                  "Gà ©§ 6­BBŽFÐ
    exit operator, it broadcasts              É  . Then each node’s message handler calculates whether the
    synchronization by exit is possible or not, and if so, it reconstructs the control area so that the related
    processes and variables are removed.

    We will explain more about our algorithm using an example. Suppose that the request messages                                       É   2 Ù Ï Ë Ó Í$Ë
                                                                                                                                           1Þbà %§ ‡0Ái  BŽFÐ   ,
É    2 ßÏ Ë §                … Qà  Í$ Ë
     ˜Bà %§ Ó 56 å #   (vƒ B€  %¬DÐ                      É                         2 à Ï Ë Í$Ë
                                                                                          1Úbà %§ Ó  %¬DÐ
                                             and                  are broadcast from P, R and Q in this order
                                                                     Ù Ï
                                                                         Ë Ó $Ë
                                                                   29€bà %§ ‡0Ái  ÍBŽFÐ É
    (see Fig. 5). When each message handler processes
                                       Á 0i                                        from P, it registers the infor-
    mation        to the variable corresponding to          on the derivation path of P. When the next message
É        ˜Bà %§ Ó 56 å #   (vú‘B €  %¬DÐ
         2 ßÏ Ë §              … Qà ƒ      Í$Ë                                                 §
      Á                                   from R is processed, a synchronization between P and R satisfies the                                       di
    synchronization conditions with
                                           and both P and R are not disabled on their derivation paths. So                                     
    is selected and executed between P and R after updating the derivation paths of P and R (P’s side, i.e.,
                                                                                                           2 à Ï Ë Í$Ë
                                                                                                           8Ðbà %§ Ó  BŽFÐ
    left, is stored in the variable corresponding to []). After that, when                             É
                                                                                             from Q is processed
    at each node, it detects that the different side has already been selected by referring the flag stored in the
    variable of [] on Q’s derivation path. So, the message is rejected and Q is terminated at          .
                                                                                                                              S "ŽdQ

     Let us suppose another different situation: if the request messages from P, Q and R have been broad-
                                                                                   É   2 ß Ï Ë §            … Qà ƒ  Í$ Ë
                                                                                       19bà ©§ Ó 6 å #   (6j’B€  %¬DÐ
cast in this order, R’s request message  0i
                                         Á                                       will enable two exclusive
synchronization       and simultaneously. In such a case, a certain policy is needed to select one consis-
tently among all nodes. To cope with this problem, we have adopted the technique based on the random
number introduced in [3, 17]. We attach a random integer to each event in request messages so that for
each synchronization, the sum of integers attached to its member events can be calculated. All nodes
select the synchronization with the largest sum.
     When       is executed in P, the behavior expression of P changes to P1 P2 and the request messages
                                                                ä &$…Í Q           HGà
                                                                                   Ù Ï                                                  Ð Ï Y E
                                                                                                                                      S "ŽdQ            â &$ …Í Q
                                                                                                                                                        ãB!BÐvà          Ù Ï
for process instantiations, say,                       -left-    -left- -left”,
                                                                              Ë    ) and       á§
                                                                                             # ‡Û‚Æ            §
                                                                                                               G)5"                                          Ë
                                                                                                                                                                    ©§         # ¬§ S
                                                                                                                                                                                 á      -
left-      -left- -right”,
          !654               ) are broadcast.
                                                       Ç "Ž3Q
3.2         Correctness of the algorithm
    Yà Þ
$ É G"Ì †Ð w                                           2
Let  Ó   Ýw &            Í ©be the current behavior expression of the whole specification where and
                                                  H                                                                                                                      H
                     denote the current inter-process relation and the set of processes, respectively. Let
      Ç Ë § Ñ Ñ Ñ $ !Ð h Ì Ð
      €%2 E†`W Ë 3à "Ï
                © e 4 É
                 denotes the set of derivable events of . Without losing generality, we assume that each
                                                           à                                          ©                                            2 $Ð Ì Ð
                                                                                                                                                    —e †RW à É uÏ
process      is assigned to -th node and has its own derivable events denoted by
                       Ë                                                                                . The                                             
                                                                                                                                                       Ë 4
theorems to be proven are as follows:                                                                      $Ð  Ì Ð
                                                                                                       2 © †`W " 3à É "Ï
Theorem 1. all nodes calculate the same event of                         to be executed.
Theorem 2. all nodes update in the same way before the next event is selected.
Proof for Theorem 1.
                                                           $Ð  Ì Ð
                                                       2 © 5`W 4 3à É "Ï              2 $ Ð Q ä §
                                                                                       %2  †Í É 3Y 4 $
    For each event in                    , let                 denote the tuple consisting of and its owner                                               
processes (i.e., the processes participating in the synchronization of ). We know that is executable
                    $ Ð Q ä
              2  †Í É 3hY H                                                                                                           2 †Í 3vY
when ,                 and the set of derivable events from all members of
                                                                         2  TÍ É 3Y
                                                                             $ Ð Q ä         are given, by the                              $ ÉÐ Q ä
semantics of LOTOS operators specified by among
             & 9e Ë                                                    .          —}½Gà ©§ Re Ë †`W 4H 3à É "%¬FÐ
                                                                                  2æ å Ï Ë 2 $ Ð  Ì Ð Ï$ Ë
    Since each           broadcasts                                  É
                                                                 , each node eventually receives the messages
sufficient to construct at least one synchronization tuple. Based on the algorithm, each node selects a
                     $ Ð Q ä §
            2B2  †Í É dvY " $                                                       $ Ð Q ä
                                                                                   2  †Í É 3hY
tuple                   such that the messages of                have been received earliest of all.
    By the assumption in Sect. 2.3, each node receives the messages in the same order as the other nodes.
Therefore, all nodes select the same event.
Proof for Theorem 2.
    The initial inter-process relation        is given to all nodes. We assume that all nodes have kept the
inter-process relation correctly this far. We prove that is updated correctly at all nodes when needs      H                                                         H
to be changed before the next event is selected and executed,
      H must be changed when each node (1) executes the synchronization event                            such
                                                                                                                                                    2 $ Ð Q ä §
                                                                                                                                                    B2  †Í É dvY " $
that its derivation paths include the choice or disabling operator, or (2) receives a process instantiation
                 …Í Q
message         or executes the exit operator.
    In (1), each node stores, in the variables corresponding to the choice/disabling operators on the paths,
the flags indicating which sides have been selected. This operation is done before processing subsequent
messages. Consequently, other exclusive events cannot be executed. In (2), a process must be invoked
            …Í Q
when         message is received, or some processes must terminate when the exit operator is executed.
Although both cases need reconstruction of , it is carried out immediately after each node processes the
message for the process instantiation or termination. Therefore, the subsequent messages are processed
based on the new inter-process relation .                                        éH
    At each node, message processing is done sequentially in order of the received messages. Therefore,
by the assumption in Sect. 2.3, Theorem 2 holds.

3.3        Implementation of the algorithm on Ethernet
In popular LAN environments, Ethernet is widely used. Unfortunately, Ethernet does not satisfy the
assumption in Sect.2.3 partly. Through an experiment on our Ethernet LAN, we have confirmed that
(i) due to the buffer overflow in ‘slow’ nodes, a small parcentage of messages may be lost when the
frequency of message exchanges is high, and that (ii) some messages are reordered on some nodes when
several messages are broadcasted in a short time period due to the loop-back mechanism of operating
     Also, in the multi-segmented Ethernet LAN consisting of several sub-nets connected through routers,
we cannot assume the total order broadcasting facility.
     For the above problems, we can use the techniques proposed in [14, 16] so that the assumption hold
on Ethernet. We can also use a well-known logical time-stamp based technique [12] so that all messages
are totally ordered among distributed nodes based on their time-stamps.
     However, for efficiency on broadcast networks such as Ethernet, here we have adopted to use a proxy
server which broadcasts messages forwarded from all nodes in an Ethernet segment. Each node does not
broadcast its messages directly. Instead it commits the server to broadcast its messages. By executing
the server at an independent node, all nodes in a distributed system can receive the messages in the same
order. By attaching sequential numbers to subsequent messages, each node can easily detect message
losses and ask for their retransmission from the server.
     Also, we can easily extend the above method to a network consisting of multiple Ethernet segments
as follows. (1) install a local proxy server for each Ethernet segment and install a master proxy server
somewhere in the network; (2) let each node in the distributed system send its message to the master
server so that after giving a sequential number to the message, the master server asks each local server
to broadcast it.
     Our current implementation includes such a proxy mechanism.

4       Implementation of the internal behavior of nodes
In Sect. 3, each process assigned to a node is supposed to obtain the set of derivable events at each stage.
For the purpose, we can use existing LOTOS compilers to generate a program for the internal behavior
of each node. In this section, we give the outline of our LOTOS compiler [23] which implements the
internal behavior of nodes as multi-threaded programs.
    We implement each process whose behavior expression is described by          © Õ(local behavior expres-
sion) in Table 2 with a portable multi-thread mechanism called PTL [1]. The basic idea of our technique
is composed of: (1) decomposition of the behavior expression to a set of run-time units (RTUs) which
contain only sequential events, choices and iterations (or invocations of several sub-RTUs); (2) mapping
of each RTU to a thread; and (3) a control mechanism to keep temporal order of events among threads
with shared variables.

4.1        Run-time unit
                                                                     © ´ # ä © Ò â Ò © G  E ä ©
To obtain RTUs, we decompose each parallel, disabling and choice expression (             ,
               6 &ë Òe ä ©
or         ) to its operands. If a choice expression has the form of
    e 5ê e  ©                                                                    5ê 6 †ÆD„  S 5ê S 6 Ž5p8
                                                                                  © ÅÅÅ © Æ ©êÆ
by    © Æ        ), we assign the whole choice expression to a thread.
    When we apply the above decomposition recursively to a given behavior expression, we obtain the
following three types of sub-behavior expressions (i.e., RTUs): choices among action-prefixed sequences

                                                                                            ïíä e e
                                                                                                            § 5ê  Æ &Çe
                                                                                            î ì                                 ë
(denoted by                    ); sequential compositions of some behavior expressions (denoted by                  ©
    2 $                           &
        © ò               ); and process instantiations (denoted by ). Let us denote by        the set    ñxÊ­ÎÊ# S ÅÊv©
                                                                                                          ð © # # ÑÑÑ #                        © # # Æ
of RTUs derived from the behavior expression . For example, the following four RTUs are extracted
2 ¯& Ï2       …à 
              v­BÐ B$    $              !6­BÐ Ï 6­BÐ © $ 2 ¯& Ï
                                        2…à          …à                             2                       …à 
                                                                                                              6­BÐ B$ wƒ         $
 C  ê Ê# #      }Æp 
                   ê ó ê   ê                                     : (1)
                                              ê p3  vf%Ð p5Û v­BÐ C 
                                                ê ó … à  ê  Ï ê  … Eà  
                                                                                         ê       , (2)
                                                                                                   # Ê#                 pDp& Ï 
                                                                                                                        ê ó ê          ê        6­© BÐ
                                                                                                                                                …à 
                 , (3) , and (4)
                             2 †A3)…
                                 $ Ð Ìà              .      ê }3 
                                                                 ê ó             p
                                                                                ê  ê                   2        C$                 ê      #
                                                                                                                                           Ê#            }Æp
                                                                                                                                                         ê ó ê
    A set of RTUs in      defined by the following function
                               ©         ô¦
                                         ó                             is said to be active RTUs.            © ò
                                                                                             Ó                        ׯ˜2
                                                                                                                      Í w w                       $ Ð Ìà
                                                                              ¬Ó  ‚  §
                                                                             2                    ©ê
                                                                                                   5Û Í ˆ Y â  ä 5(3)… õ¦         © ê $ Ð Ì à ó
                                                           ‡â †(3)… # ‡§ ‡ ä  46  3)… Ë Êw µË ©
                                                           2 $ Ð Ìà                     (2 5(Ì à
                                                                                        Ø         $Ð                      w§ ©                              õ¦
                                                                   © ‡õ¦   Ó óâ                © ä ×Êd¬â
                                                                                                      Í       ów õw¦ 2                           $ Ð Ìà
                                                                                                                                             ä 5(3)…
                                                                                    ׯ# ©
                                                                                   © #                                   ¯‡Í w
                                                                                                                         Ó &  © ×# ¯w 2 & $ Ð Ì à ó
                                                                                                                              xÊ# ‰¯©B5(3)… õ¦

4.2            Basic idea to implement the interaction among threads
We implement the choice between two expressions
                                                                                         ä      â
                                                               by executing the threads corresponding to
 ‡â †A3)… ú‡ä 5(3)…
2 $ Ð Ìà    Ø 2 $ Ð Ìà                                                               ©
                                                                                     6  ©
    ©    õ¦
         ó      ©      ó õ¦in parallel with a shared variable as follows (here we assume a mutual exclu-
sion mechanism called Mutex in our portable thread mechanism [1] to avoid the simultaneous access to
shared variables from several concurrent threads):
         È      2 $ Ð Ìà ó
                 ¬ä © †(²… õ¦
               A thread in                      which has been permitted to access the variable earlier than the threads in
                               2 $ Ð Ìà ó
                               ‡â © †A3)… ô¦                                      2 $ Ð Ìà ó
                                                                                  ¬ä © †(²… õ¦
                                   stores in the variable a flag that            ’s side has been chosen.
         È     When another thread in
                                                     2 $ Ð Ìà ó
                                                     ‡â © †A3)… õ¦       ) accesses the variable, it knows the other side has already
               been executed, then it terminates.

    Similarly, we implement the disabling expression
                                                     ‡â © 5(3)… õ¦
                                                    2 $ Ð Ìà ó                            x # ä ©
                                                                     by executing the threads of
                                                                                          ©          â                                            ¬ä © †(²… õ¦
                                                                                                                                                  2 $ Ð Ìà ó
and               in parallel with a shared variable.
    When multiple operators are hierarchically specified among multiple sub-behavior expressions, for
example,     ÷è©k #
                     2                      2              $
                     B2 öÞ© E Á © $   ‡â ©  ä © %$
                                           , we should have threads be able to refer the variables hierarchi-
cally. Therefore, we allocate in each behavior part for a given process the work space consisting of some
shared variables called local control area which has the same structure as that of operators specified in
the behavior expression of the process (Fig. 5). The directed path from the leaf (to which each thread
connects) to the root in the local control area, is called local derivation path of the thread.

4.3            The control among RTUs
For each thread , if each operator on its local derivation path is either choice, interleaving or disabling,     …
and if at each operator other side threads have not been executed at all, can execute one of its derivable
events. In that case, selects one of them at random. Otherwise, it terminates since it can execute
    If the synchronization operator (      ) is on the local derivation path of a thread, the thread has to
communicate with other threads to decide what event should be executed. In general, we need the fol-
lowing steps to decide what events can be executed if the synchronization operators are specified among
some threads: for each synchronization operator (       ), (1) identifying all derivable events with the gates
in for the threads of its operands; (2) calculating the pairs of events which satisfy the synchronization

                                                   ø   left                         right

                                                 a!5!true                           a!4?w
                                                       ù   (3)
                                                                                    ù   (2)

                                                                                              ø                                                       ø   left side
                                                                                                  local control area                                      selected
                                  ø       left                   right                                                                                         ù
                                                                                                                  |[a]|                                            (3)
                                a!5!true                   a?y!false
                                a!4?x                      a?z!true
                                      ù   (1)
                                                                  ù   (3)                         |[a]|
                                                                                                                                    ú   []

                                                                          ù   (1)
                                                                                                   ù   (3)
                                                                                                                          ù   (2)
                                                                                                                                                 ù   (4)

                                                                      û   F1
                                                                                                         û   F2
                                                                                                                                        û   F3
                                                                                                                                                           û   F4

     Figure 6: Control mechanism to implement multi-way synchronization among local processes

condition in Table 1 and whose guard expressions hold; and (3) selecting one of the pairs and propagating
the decision to all related threads.
     If the synchronization operators are specified with the choice, interleaving or disabling operators,
several mutually exclusive combinations of synchronization events could become executable and one of
them should be selected in a nondeterministic way.
     In the proposed subclass of LOTOS, some processes can be invoked dynamically and undefined
variables may have various values as the initial behavior expression progresses. Thus, in general, it
can be decided only dynamically whether the synchronization condition and the guard expression of
each synchronization hold or not. Therefore, in order to select one of multiple mutually exclusive syn-
chronizations fairly, first we have to detect all possible synchronizations whose conditions and guard
expressions hold. In multi-threaded code, however, dynamic detection of all possible synchronizations is
costly because all related threads have to be scheduled (given some CPU time) at least once. Therefore,
we have adopted a policy making multiple groups of threads to evaluate the synchronization conditions
in parallel and to select the synchronization of the group which finished the negotiation earlier than the
other groups.
     Below, we explain our algorithm using an example in Table 4. In our technique, the processes F1,
F2, F3 and F4 are mapped to different threads and invoked in parallel. For the sake of clarity, we suppose
that F1, F3, F2 and F4 are scheduled and have permission to access the local control area in this order
(Fig. 6).
     First, F1 and F3 store the information about their events in the variables of      closer to the leaves                                                             
on their local derivation paths, and wait the synchronization peers. Next, F2 stores the information about
its events (a?y:nat!false, a?z:nat!true) in the variable of      closer to the leaf on its path, and checks                    
                                                                                                                               G5 E
if the synchronization peers exist or not. In this case, the events of F2 and the events of F1 satisfy the
synchronization condition in Table 1. Then, F2 substitutes the event value of F1 to its undefined variables
(a!5!true, a!4?x:bool), and stores the information about that in the variable of upper      (Fig. 6(3)). The                                                                       
part of the information and that stored by F3 satisfy the synchronization condition. So, F2 obtains the
unified events (a!4!true, a!4!false). Since there is no upper synchronization operators, F2 selects one of
them at random, and informs other processes of the selected event through the variables of two             s.                                                                                
Processes F1, F2 and F3 execute the selected synchronization after updating the information on their

                           Table 4: Behavior expression with some exclusive synchronizations

           process Q[a,b,c] : noexit :=
             ( F1 a F2 ) a ( F3 [] F4 )
                  ¨þ ý ü     ü
                             ¨þ ý ü
             F1 := a!5!true; stop [] a!4?x:bool; stop
             F2 := a?y:nat!false; stop [] a?z:nat!true; stop
             F3 := a!4?w:bool; stop
             F4 := a?v:nat!false; stop
           (Here, the declarations for processes F1 – F4 are simplified)

paths (i.e., F3 stores the flag, e.g., left, in the variable of on its local derivation path).
    Afterward, F4 calculates another possible synchronization with the events of F1 and F2. However, it
knows the other side has already been selected at [], and then it terminates.
    Here, let us consider another case: e.g., F3 offers event a!5. If we assume that the scheduling
order of threads F1 – F4 is the same as the previous case, F3 waits for its synchronization peer in the
variable of       on its local derivation path, but cannot find forever. So, then F4 calculates a possible
                 G5 E
synchronization (a!4!false) among F1, F2 and F4, and stores right in the variable of [] before executing
the synchronization. Finally, F3 knows that the other side has been selected at [], and then it terminates.

4.4        Implementation of abstract data types
In LOTOS specifications, we define data types and operations/functions in the algebraic language called
ACT ONE [5], and use them in the output values of events (e.g.,
                                                                                            2  ó i
                                                                                            8`$ pó ‚0Íi 
                                                                                   ), in the guard expres-
    æ 2  $  § å … a 2  Q ƒBÍ  2 € $ a
© # ) (g § `Aá 46 "œ(®g… $  (×B8R fR$
sions (e.g.,                                       ), and in the parameters for process instantiations (e.g.,
                               }ó §
                               ó            )Æ!5"  &
    In ACT ONE, operations/functions are given by the set of axioms in the class of general conditional
term rewriting systems (CTRS). So, we have to rewrite the given expression repeatedly until its normal
form is obtained.
    Since there is no efficient implementation for CTRS, here we restrict the forms of axioms to be
functional 2 in order to get more efficient implementation for the operations/functions. We transform the
axioms in the subclass of ACT ONE to those in the functional language ASL/F, and then automatically
obtain the corresponding program with our ASL/F compiler [7, 8]. The transformation needs just the
syntactical conversion due to the similarity between these two languages. 3
    For the use of any data type in LOTOS specifications, we have added to our LOTOS compiler the
facility to describe data types and functions in other programming languages like C. To use such external
functions/operations, we just define the names for the data types/functions in LOTOS specifications. In
[24], we have proposed a visualization technique for LOTOS specifications, using the external graphic
library for animating the system behavior.
     only the axioms in the form of
                                        ª ™Ã 6„}™©¨ 9qª ™Ã )º }™¢ æ ÿ
                                              ú ¢ „ „
                                               ¡ ¡   £
                                                             Ã        and the axioms for if–then–else statement are allowed
                                                                     ¡ ¡   £
(here, is the expression composed of the variables
                                                  }™Ã à º ™  and the functions
                                                           ¡ ¡   £                  ÿ  .
                                                                                        à ú
                                                                                          ¡ ¡   ÿ
     The following operators are currently not supported: formalsorts, formalopns, formaleqns, actualized by, using re-
namedby, sortnames and opnnames.

5                      Applications
In this section, we describe some typical distributed systems within our subclass of LOTOS proposed in
Sect. 2.2.
Example 1. Duplication system
     Let us suppose that a service is duplicated for high reliability. In the case that each service process
fails rarely, it may be reasonable to make several processes carry out the same task and to select their
majority by obtaining the results from those processes.
     We describe a request for each task as
                           Y É &†36ŸàW
                                 iÐ Q             FFÐ
                                                  Í Í ¨
                                                        , and an output of the result after processing the
                                                              î      úFÍ R$
                                                                     2î …
                                                                                                      É         …€Ë
                                                                                                               ‚ŽFÐ                î
                                                                                                                                                 Ð Q Ë
                                                                                                                                                 dvŸàW FÐ                       YÉ &       FDÐ
                                                                                                                                                                                           Í Í¨
                                                                                                                                                                                              §        Í       …$
                                                                                                                                                                                                               Rúî       î
                                                                                                                                                                                                                         FÍ   2
task as                             in the following process
                                              ó                          (here,                       is an                                    § î Í É ¨Ô…                         ó                            
abstract data type function which calculates the result from        ).                                                                                    
©                                                                                                                       ©
        ý   4 2 1                þ
                  E 2 2  B A  9 8  !  5 4 2 1
            3GFDC@¤¦#" 763¨ ¦)('% #" |
                                                  0    & $  !                          u ¸|"
                                                                                               u s3¨
                                                                                                  4 2 1         H
                                                                                                                5                   þ !    
                                                                                                                                    £#"  ý
    Next, we describe another process called Checker which obtains the results from duplicated processes
and outputs the correct result based on the majority or detects an error. Checker receives three results:
g                                                                                                                                                                                                                                g 
  , and from three processes, respectively with multi-way synchronization. If more than two of
                             I                                                                                                                                                                                                     §
                                                          g R!… Ð Y                  2                                                                                 g R$ Y
                                                                                                                                                                               i… i
                                                                                                                                                                                !­bY                       2
and are the same (
               I                                        § § ó ÉÉ 
                                     ), Checker outputs their majority (         I
                                                                                 ¦          ) and repeats                                                            § § É xÌ    P
                                                                                                                                                                                  ¦                I

the procedure. Otherwise, it executes the event      to stop all processes. Checker can be described as           ÉÐ            É
                                      þ        | aA Y  W U ý  4B
                                               "b)`¤!¨)X! ¨CV! ¢ÛFD
                                                              & $    
                                                              c H¨¨

                u  5 0                ü | ~5 g0 W  ü | ~5 ~ U 
                 G|`6~6D3ifY`! ¦ü ü(ØR6)7`hfX! C(ü(üØR66DevQR0 V! ds                                          S
                                                               s |B   ý p
                     s  x v 8 | a p p tdþŽ¨rd%}~G`)bR A s qp
        5HuŽi¨rgd%~}"bAy1w¤"uA                s u i  g                                                                     þ     | a A  Y   W   U !ý   4 B
                                                                                                                                ÆH¨¨‡b¨)X! X! C¤¤FyD
                          A | 2 5          s u i  g    s |B    |A ý
                      u ƒb¨)7fF tdþŽ¨‚h%}~G`CbA ©#! ã ýþ
   We invoke three identical processes S in parallel on nodes 1, 2 and 3, which send the results to
                                                              dŸQW     â Q
                                                                       ΟW               Á Q
Checker via three gates  ,     and    , respectively. The whole system can be described as follows:
                   ©                                                         ©                                                                      ©
                                                                                 üþ   ü u „ü ˆ  … A ü „ s þ W    
                                                       üþ   ü u „ü ‡  … A ü „ s þ U    
                                                                                 ¨‰) ý H†'}††C#! DFFÆX! ) ý
                                                       ¨‰) ý H†'£††C#! DhF)V! ¨ ý As                s                                              DFFÆX! ) ý
                                                                                                                                                         ü „sþ Y       ' ††C#!uu ü
                                                                                                                                                                                  )† }
                                                                                                                                                                           „ ‰  … A

                                                               f†'„}C†C€R ! DFFÆH¤bCVt p ý
                                                              u u ü   … S#ü „ s þ   ý  A  

u†c„üf†…CA#! üD„FsFþÆH7¨|"abAYX! )W`¤!¨CV! ¤Fy¨ ¨ÆCF¨)X! )`! CV! S ¤ý ü
                                                       U      ý  4B           üþ   Y   W   U
                                                            ƒ A | 2 5      & $ þ    ý  A   t  

Example 2. Client server system with load sharing
    In client server systems such as VOD (video on demand) systems, a series of data streams is trans-
ferred successively between client and server systems.
    If video data must be transmitted from server machines to each client machine and if we prefer
to make several nodes share their load to execute a server process, such a client server system can be
described, for example, as follows:
    ©                                     ©                             ©                                                   R                                   R
         ü u u „ ü ‰  … A ü „ ü ü u „ ü ˆ  … A ü „ ü ü u „ ü ‡  … A Ð ü „fÞ
       ý H)5c}†C#! Dhs (ü 3†cp†C#! ÆFs ü (3†'C†C#! Dhs Is ä                                            “     sü
                                                                                                                †#þ                  ü „su U
                                                                                                                                     DF)Hs     ”¦#!
                                                                                                                                                  … A    DF)"•s ((†cü
                                                                                                                                                          ü „ s u W üüü u „   ' QC#! )† 
                                                                                                                                                                                      uu ü
                                                                                                                                                                              „ –  … A
                             2Ï $ à                 Ï €Ë
                2 ˜Ô ¸ ¬Gà ó †Ð ó 4Ì É Ð Ô $ ê Gà ó ŽFÐ H i Ï Ewƒ Ô
                                                                    Ð É fIä
                   Ï iÏ Ï Ï Ì€ îÍàÏ ƒ 2Ï $ à
  à4Ì É Ð !ê AÌ uGà ó i )ê AhúF¥Áwh"bà ó †Ð ó 4Ì É Ð Ô
              Ô "Bà †f3BÐ Ð DÐ uGà i Ew9"bà $                                                                       Ð
                      2 Ï ó $ Ð Ì à ó ê Ë H i Ï ó Ï ƒ 2 Ï ó 
                                        H                               ÐÞ
                                                                   Ð É fIä
      Ð Ìà H …Ð ó  € Ï                            ƒ 2 Ï $ Ð Ìà
      (3%Ð ó Ð 5ê Búî fË "Gà ó i Ï w¾"bà ó †A3BÐ ó Ð H
(Here,                 ™    denotes a gate for exchanging video data.
                                                                                               E¤²±       denotes the identifier of the client. We assume that
                                                                                                                                                                                                 !F5 )¥¤
                                                                                                                                                                                                 ¤ ·À §¦

    to the internal action to read a video data fragment from the disk.)
        In the above specification, since the identical server processes is invoked on nodes 1, 2 and 3, each                      â                                                                                         e

    of two client processes       and       can communicate with one of them which are ready to serve.
                                                                       j i g
                                                                       7hf                                          g
                                                                                                                     hf                               j

        Let us consider the case that each client can switch to another server if the average transfer rate
    of video data gets less than the expected value. Using the constraint oriented style of LOTOS, such a
    mechanism can be added without largely modifying the original specification as follows.
    hk           R        k                                 © k    k                                                      ©                       k                             ©   k                                                   R k   k            k                             R   k        k

s q
                              ü      ü n „ü m  … A ü
                              ¨þ “ ý 3QcDu†C#! Ds „                    üüü n „ü ‡  … A ü
                                                                       ((”c£3†C#! D„                                                                     ü (3”'}†¦e! D„
                                                                                                                                                            üü n „ü ˆ  … A ü           ¨þ “ (ÛH”cp†C#! Ƅ
                                                                                                                                                                                        ü ýü n n „ü o  … A ü                                         n
                                                                                                                                                                                                                                                      QU       D„
                                                                                                                                                                                                                                                               ü     †C#!
                                                                                                                                                                                                                                                                       … A     üü n „
                                                                                                                                                                                                                                                                              ü (3”'ü            fW
                                                                                                                                                                                                                                                                                                 n        ü
                                                                                                                                                                                                                                                                                                          D„            
                                                                                                                                                                                                                                                                                                               FH”c †C#!
                                                                                                                                                                                                                                                                                                               n n n „ p  … A
             w u                   ...(* the same as above *)
             •@6H hfó
             w u j y x g                  ...(* should be slightly modified for server switching *)
                                                          Ds                      s                     Í
             z                                                                                                                                                                                  z
                       w u
                        |{f            Ï
                                       }    ó
                                            €  y x               3Ht¦ê
                                                                  Ïxg                 É       }            p
                                                                                                            Š Š Š j ‰ ‡  ˆ ‡ y x † g … ‚ „  ƒ ‚
                                                                                                            c|CyQ¨¦6b7t3‚b%hQ                 f                                                    j
                     s     s

                     w u j    Ž ˆ ‡  ˆ ‡ y x † g … ‚ „  ƒ ‚
                           s           s                                                   s
                              “ † ’ ‘ } y x † 
                               fX¨6b|                  x  ”
                                                          hbuC              }
                                                                             ‚„                ”
                                                s                                                                s                                                   z                                         q                    s
                                                   g      Ž ˆ g y ƒ ’ j   ™     ˜   ˆ     –      • g
                                                                                                  g QDg              ž j  ˆ
                                                                                                                     œD—˜  –                                           |6b| šF"j
                                                                                                                                                                         f  y x †     ˜ – Ÿ                         ¡ ƒ
                                                                                                                                                                                                                       %Q’              j ‘ ‚  ˆ
                                                                              s            s
                                                                                           tq                                                                               s          s
                                                    … ‚ „  ƒ ‚    f  ˜   –     ˆ x     „     ‚ QFŸ •
                                                                                                • g                                                                                         “ † ’ ‘
                                                                                                                                                                                             ft"g          j j j j
    (Here, we assume that                                ¥ ¬ « ª
                                                         d”DG©§¥ ¨ ¦         denotes the internal action to obtain the current time from the system.         means the                                                                                                        ³ ² ° ¯ ª ® ¦
                                                                                                                                                                                                                                                                              ¦±Q©t­                ´ ¥
    function to obtain the size of                                     ¦°
                                                                       ³ ²       . and denote the monitoring period and the expected transfer rate, respectively.)
                                                                                      Dª            µ                                     ¶
        The above constraint process          invokes process      when a connection is established, and                              f                                                             … ‚ „  ƒ ‚
    process            examines whether the monitoring period has passed (
                                     … ‚ „  ƒ ‚                                            )and the average                                                                             s
                                                                                                                                                                                                                                                       ™ ˜  ˆ
                                                                                                                                                                                                                                                       ¸vD{·  –
    transfer rate gets less than the expected value (                ). If this is the case, it tells the fact to                                                        g   Ž
                                                                                                                                                                         ytDˆ                ž j  ˆ
                                                                                                                                                                                              œDw˜  –
                                                                                                                              q                                s
    the client process by event                  .                           f  y x † 
                                                                             |6H|                                                                  ¡ ƒ

    Example 3. Mutual exclusion system
         In designing a distributed system, frequently we treat the mutual exclusion such that a resource placed
    at a node can be used by at most user processes simultaneously.                                          “

         If each user process uses the resource A after          and releases A before            , the restriction                                                             “ † ‚ … 
                                                                                                                                                                                3t|f’                                                                                 “ † ‚ … ƒ
                                                                                                                                                                                                                                                                       C†tœXŽ 6’ 

    for A can be described as follows:
    w u j » º ’  ‡ „ ˆ Ž g Ÿ •
    |@QuDVtFQ’ ¹€

    ¾½Q~7 €D@"H¦’ ¹Q‚3tœXŽ fXŸ ½D@˜Qu—qDVtFQ’ ¹¦‚C†t•6ššH%¦ ¼DVŽ Qg
    j » º ’  ‡ i – „ ˆ Ž g Ÿ • € ” “ † ‚ … ƒ  ’ • j j » º ’  ‡ i ¢ „ ˆ Ž g Ÿ • € ” “ † ‚ …  ’ ˜ – Ÿ » º ’  ž „ ˆ •

     À ¿ ²                         denotes the number of user processes which can use the resource simultaneously)
        If processes           using resource A can run independently of each other except the access to
                                                       à ™ ‡    ‡ Á

    A, the whole system can be described as follows:
                                                   s                                                                                          s                                                                    s                                                                                             s
                 y ‚ Š Ä g Ÿ • Á ™
                 3¾ƒ XDF¦’ †˜7g                        y ‚ Š Ä g Ÿ • Å ™ Š Š Š j Š
                                                       3œƒ t7FQ’ t#|•œÄ 3Á                                                                              3¾ƒ XDF¦’ @œ||t||||qyÄ fÅ
                                                                                                                                                          y ‚ Š Ä g Ÿ • à ™ Š Š Š Æ Æ Æ Š Š Š j Š                      y ‚ Š Ä g j » º ’  ‡ ‰ g Ÿ • € Š Ÿ • Š j j Š
                                                                                                                                                                                                                       3¾ƒ t7D#q¦7yDF¦’ ¹¨¦’ |”7yÄ eà                                                              j Š
                                                                                                                                                                                                                                                                                                                     Ä QÁ

        In the above specification, events         and            in process synchronize with one of                                           “ † ‚ … 
                                                                                                                                              3t|f’                      3t¾tŽ f’
                                                                                                                                                                          “ † ‚ … ƒ                                            €                                                                           à ™ ‡    ‡ Á

    and increase and decrease the value of       , respectively. If        exceeds       , only       can                                                  DVŽ
                                                                                                                                                           „ ˆ                                           i ¢ „ ˆ
                                                                                                                                                                                                         —·¨VŽ                                                      » º ’
                                                                                                                                                                                                                                                                    V¦                         “ † ‚ … ƒ
                                                                                                                                                                                                                                                                                                 3t¾tŽ f’ 

    be executed. In that case, processes which want to use resource A, must wait until A is released by
    3tœXŽ f’
    “ † ‚ … ƒ .

        We can easily extend the above system to treat several resources, say, A, B and C, only by adding
    processes for restricting those resources as follows:
                 7œQ~7yDFH† Ë7|•¾ÊQ~7yDFHÈ ¹H|•˜›Q~7yDFQ’ ¹7h¨Hf’ cQHHQQ6’ q7||•|u•|fb¦¦f’ t@7||‚H¦Q6’ @7g
                 j j Ì º ’  ‡ ‰ g Ÿ • € Š Š Š j É º ’  ‡ ‰ g Ÿ • € Š Š Š j » º ’  ‡ ‰ g Ÿ • € g Š Ÿ † ‡ È ‡ • Š j Ÿ † ‡ È ‡ • à ™ Š Š Š Æ Æ Æ Š Š Š Ÿ † ‡ È ‡ • Å ™ Š Š Š Ÿ † ‡ È ‡ • Á ™

    (Here, the node assignments are omitted)
                     In this way, we can simply describe the complicated control mechanism among processes with the

    Table 5: Performance of parallel execution of
                                                                       Table 6: Performance of alternative execution of
    events (events/sec.)
                                                                       events (events/sec.)
          No. of                    LCC        COLOS   TOPO
                                                                           No. of         LCC      COLOS                TOPO
          100                         765        830    123
                                                                           k=5              417              550             448
          200                         737        443     56
                                                                           k=10             328              561             333
          300                         705        318     35
                                                                           k=15             261              569             241
          400                         680        242     25
                                                                           k=20             214              568             173
          500                         665         —      19

    resource oriented description style [22].

        As explained above, in the proposed subclass of LOTOS, we can describe simple and structured
    specifications for typical distributed systems with multi-way synchronization as well as other LOTOS
    operators among processes over nodes.

    6     Evaluation
    6.1     Performance of the internal behavior of nodes
    Total performance of distributed code largely depends on performance of the internal behavior of each
    node. Therefore, we have compared our compiler with other compilers, COLOS [4] and TOPO [15].
    TOPO is a very general compiler which supports full LOTOS with ADT data types. TOPO generates
    architecture-independent code where a given LOTOS specification is first transformed to an abstract vir-
    tual machine and then to C or Ada code. COLOS [4] uses a multi-thread library called LWP of SUN
    operating system (therefore, its code is architecture-dependent) to implement LOTOS specifications.
    Unlike TOPO and our compiler, in COLOS approach, the choice operator among non-action prefixed se-
    quences and the disabling operator are not supported in order to simplify the synchronization mechanism
    among processes.
        We have used the version 3R6 of TOPO and the version of COLOS included in MiniLite3.0. Here-
    after, we refer our compiler by LCC (Lotos to multi-threaded C Compiler).

    Basic performance
    First, we have evaluated the performance of the generated programs in terms of the number of parallel
    processes. Here, we have used the specification containing processes combined with the interleaving

    operators (i.e.,            ), where each process repeats the sequential execution of 10 simple events
                             Š Š Š Æ Æ Š Š Š
                           ™ ||H||Æ ||͙                      ™

    QCtt¦•||Q††¦fΕΙ       ). We have measured the number of events executed in a second for the range of
    ™ ” Ï Á ’ ” Æ Æ Æ ” Å ’ ” Á ’ w u

ƒ     between 100 and 500. The experimental result on Sun SPARCstation IPX (52MB RAM) is shown in
    Table 5.
        According to the Table 5, the compilers with multi-thread mechanisms (LCC and COLOS) produced
    about 10 times as fast programs as TOPO, although the program generated by COLOS cannot be executed
    correctly due to memory errors when the number of processes is 500.
        Secondly, we have executed a choice expression with several alternative events to evaluate its perfor-
                                                                                                        s                         s
    mance and fairness. We have used the behavior expressions in the form of              ” Á ’ g
                                                                                          ¨˜7š•ÑÐ w u       ¦fFŸ F|•FŸ )htº
                                                                                                            ” Ò ’ • Æ Æ Æ •  x       ˜ ˜ j  x

                 Table 7: Example specification
                                                                                                             Table 8: The efficiency in multi-way synchro-
Ú Ó Õ Ø × Ö Õ Ù Ù Ù Õ Ø × Ö Õ Ô
                                                                                                             nization execution (seconds)
Þ ß Þ Ü
             å Ô
             •k €äcrÓ
                 ã â á à
                                        •k ©ç¢¢'±c''c'Õ
                                           è Ô ã Õ Õ Õ æ æ æ Õ Õ
                                                                                                                # of procs.
                                                                                                                  ë           7÷
                                                                                                                                    LCC     COLOS         TOPO
     Þ ß Þ Ü
                    rthk ˜ã
                   ì ë ê é        ë á      ì ×
                                                       ~tØ ðVrtê ícá
                                                       ò ñ   î ì ë Ö â
                                                                                                                  ë       å ÿ
                                                                                                                                      9.1       6.0         26.3
                    uy× ô ¨Ù ¨Ô uC×
                   ó é    Ù Ù ô ó é                  7ô ¨Ù D7ô
                                                     õ  Ù Ù ô Ô õ       ÷ ø#rthk œã ô
                                                                           ö ì ë ê é
                                                                                                                                     19.8      22.3        109.3
                                             p                      p                      n                      ë   â   ¡     å
                                                                                                                                     29.7      52.8        260.1
                                                                                                                  ë   ¢
                                                                                                                      â         å
                                                                                                                                     39.8      97.4        477.7
(here, each process declaration is simplified.                                  ©ü dú²
                                                                               ü þ ý û ù   repre-                 ë   â   å

sent output events via a and b, respectively)                                                                                        52.4     159.6        759.9

Ð  which is in the scope of the class COLOS supports. We have measured the number of events executed
per second for the range of between 5 and 20. We show the experimental result in Table 6.

     According to Table 6, the performance of programs generated by COLOS is independent of the
number of alternatives, since the programs always select the first alternative. Programs generated by the
other compilers selects each alternative fairly but the performance depends on the number of alternatives.
Here, the difference is due to the fact that COLOS implements choice among events deterministically
by ‘if–then–else’ code, while the other compilers do this by fairer method (e.g., with random numbers).
If fairness is not needed, we can modify the LCC compiler to generate ‘if–then–else’ code in order to
achieve similar performance to COLOS.
     Finally, we have executed LOTOS specifications containing multi-way synchronization among mul-
tiple processes. We have used the behavior expressions in Table 7. Here, we specified processes to                                               ƒ

execute events on gate synchronously by multi-way synchronization. We specified each process
                                                       ’                                                                                                           ¤

composed of 10 parallel sub-processes (                   ) so that multiple combinations of synchronizing
                                                                                     Ï Á Š Š Š Æ Æ Š Š Š Á
                                                                                     t̀ ||F•|Æ •|̀

processes are produced. We specified each           to sequentially execute 5 synchronous events on gate
                                                                                               €                                                                       ’

and 5 asynchronous events on gate , alternately. Here, we have measured the time duration between the

start and end points of the execution of the corresponding programs, alternating the value of between                                                 ƒ

10 and 50. We show the experimental result in Table 8.
     Table 8 shows that the time consumed by LCC’s executable code is approximately proportional to
the number of synchronizing processes. The execution time of other compilers’ is getting much longer
as the number grows.

Protocol implementation
In order to evaluate the performance of real-life protocols, we have generated executable code from a
LOTOS specification of the Abracadabra protocol [10] with our compiler.
    This specification specifies the behavior between upper layer (i.e., user) and lower layer (i.e., com-
munication medium) within a node, and is consisting mainly of 6 parallel processes and several extra
processes which can interrupt the main behavior. In the protocol, a data file is divided into multiple data
packets and the packets are transmitted via an unreliable medium.
    We have slightly modified the original LOTOS specification in [10] as follows: data types such
as FIFO queue are described with our standard data type library written in C; two extra processes are
added for the upper and lower layers where the upper layer process performs connection requests and
confirmations, while the lower layer process simulates behavior of communication medium and the peer
node. In the specification, each data packet is transmitted from the service user to the lower layer by two
multi-way synchronizations.

                          Table 9: Performance in transmitting 1 Mbyte file by the Abracadabra protocol

                 Packet Size                                    256 byte                       512 bytes               1024 bytes                           2048 bytes
                 (# of sync.)                                   (7817)                         (3911)                  (1957)                               (981)
                 TOPO on Solaris                                167 sec                        111 sec                 88 sec                               93 sec
                 Trans. Rate                                    6.0 KB/s                       9.0 KB/s                11.5 KB/s                            10.8 KB/s
                 (dur./sync.)                                   (21 msec)                      (28 msec)               (45 msec)                            (95 msec)
                 LCC on Solaris                                  53 sec                         28 sec                 17 sec                               12 sec
                 Trans. Rate                                    18.9 KB/s                      35.7 KB/s               58.8 KB/s                            83.3 KB/s
                 (dur./sync.)                                   (6.8 msec)                     (7.2 msec)              (8.7 msec)                           (12.0 msec)
                 LCC on FreeBSD                                 6.99 sec                       3.53 sec                1.80 sec                             0.91 sec
                 Trans. Rate                                    143.1 KB/s                     283.5 KB/s              554.7 KB/s                           1096.7 KB/s
                 (dur./sync.)                                   (0.89 msec)                    (0.90 msec)             (0.92 msec)                          (0.93 msec)

    In the experiment, we transmitted 1 MByte data with varying the packet size from 256 to 2048 bytes.
The experimental result is shown in Table 9 (Solaris 2.6 on Sun SPARCstation 5 with 64MB RAM). In
the table, we give a comparison with the TOPO’s executable program, just to give index.
    According to Table 9, the LCC’s executable program can transmit files at about 20 to 80 KByte/sec
on the SUN workstation, which is about three to eight times as fast as TOPO’s. In another experiment on
a FreeBSD-3.1R machine (with Pentium III 450MHz and 192MB RAM), we confirmed that the nearly
same specification (with ADT primitives which treat data packets as binary data) could achieve more than
1 Mbytes/sec (see the last row in Table 9). We think this result will be sufficient for rapid prototyping of
    Table 9 also shows that the duration for the file transmission depends not only on the number of
synchronizations, but also on the data packet size (see dur./sec variation against packet size). Thus, the
time consumed by data type operations grows as the data size becomes large. This tendency is prominent
especially in TOPO’s program since TOPO directly generates the executable code from the ADT parts
of LOTOS specifications.

6.2          Performance of distributed systems
To evaluate our implementation technique in Sect.3, we have examined the efficiency of programs gen-
erated from several specifications of distributed systems.
    The programs were executed on several FreeBSD3.1R machines with 32 to 64MB RAM and Pentium
100 to PentiumPro 200 processors on 10BASE/T Ethernet.

Basic performance
First, we have executed programs generated from the following specification where each event synchro-
nizes among processes on different nodes repeatedly. The experimental result is shown in Table 10.

Ó   ¨  ©¨
    k ëÕ    Õ Ô Þ
                          Ó Õ
                                ¨   ©¨
                                k   ëÕ
                                         Þ   Õ
                                                     Ó Õ Õ Ù Ù Ù Õ
                                                     'ch¨¨cÕ        ¨  ©¨
                                                                     k ëÕ
                                                                              Þ   Ú   Õ
                                                                                          n   where
                                                                                                      Ó   ×
                                                                                                            â   Ó Ô
                                                                                                                  ô    ×
                                                                                                                       "Ø Ö      Ó ô   "Ø F7¨†Ø Ö
                                                                                                                                        × Ö Ù Ù Ù 
                                                                                                                                                     Ó ô

   Table 10 tells us that a simple synchronization without data transmission among a small number of
nodes can be executed in reasonable time (i.e., over 100 synchronizations per second among 5 nodes).

Table 10: Performance of simple synchro-
nization (synchronizations/sec)
                                                                                                                                                 Table 11: Performance of a mutual exclusion
                                     ƒ           n=2                        n=3           n=4              n=5                                   system (synchronizations/sec)
                                k=1              940                        777           639              570
                                k=2              632                        529           425              372                                                     n=1           n=2         n=3          n=4          n=5
                                k=3              458                        365           316              262                                                     674           681         582          585          591
                                k=4              431                        285           241              193
                                k=5              408                        223           184              141

                                     Table 12: Data transmission rate over distributed nodes by multi-way synchronization
                                                   packet size         n=2             n=3            n=4
                                                         1 KB 123.13 KB/s         57.69 KB/s     46.27 KB/s
                                                         2 KB 229.25 KB/s 111.61 KB/s            86.78 KB/s
                                                         4 KB 329.43 KB/s 204.29 KB/s 160.42 KB/s
                                                         8 KB 402.89 KB/s 348.60 KB/s 284.44 KB/s

The performance depends on both the numbers of processes and alternative events ( and ). The latter                                                                                                                ƒ     “

is due to the cost of selecting a synchronization of several exclusive ones.
    Secondly, we have examined the data transmission rate over distributed nodes with multi-way syn-
chronization. In our example specification shown below, a sender process located on node 1 successively
distributes a fixed size packets to        receiver processes on several different nodes by multi-way syn-  i –

chronization on gate .                                                  ¡

  # ¨  ©¨ #  "
          ë              ß
                                k †Ö
                                  Ø         ëÕ
                                                      Þ   Õ Ô
                                                                                t” ±Õ
                                                                                Õ Ø Ö

# ¨ '  ©¨ # &%©$
ã k           Þ
                      Þ        ß Þ
                                         k †Ö
                                           Ø     ëÕ
                                                                Þ           Õ
                                                                                     Ct† ±Õ
                                                                                     ã Õ Ø Ö   Þ
                                                                                                   ê   ¨  ©¨ # )%($
                                                                                                         ß Þ
                                                                                                                 k †Ö
                                                                                                                   Ø    ëÕ
                                                                                                                                               Ct” ±C'cæ
                                                                                                                                               ã Õ Ø Ö Õ æ æ   Þ
                                                                                                                                                                       ¨  ©¨ # )%©$
                                                                                                                                                                       Þ   ß Þ
                                                                                                                                                                                 k †Ö
                                                                                                                                                                                   Ø    ëÕ
                                                                                                                                                                                              Þ   Ú   Õ

(definition of each process’s internal behavior is omitted)
    In Table 12, we show the result with the size of a data packet from 1 to 8 kilo-bytes (KB) and from                                                                                                                      ƒ

2 to 4. The resulting rate is about 46 to 284 KB per second when the number of nodes (a sender and
receivers) is four (123 to 402 KB/sec for         ). Since we use a proxy server explained in Sect. 3.3,                 šƒ
                                                                                                                         w   0
we need double bandwidth for message transmission. If we assume the actual bandwidth of 10 Base/T
Ethernet to be 8 Mbps (i.e., 1 MB/sec), the ideally maximum transmission rate with the proxy server
is about 500 KB/sec. Taking this into consideration, the resulting rates could be reasonable especially
when the packet size is over 4KB. On the other hand, the transmission rates are rather low when packet
size is small. This may be caused by synchronization delay at each node. For each synchronization,
each node has to wait message receptions from all other nodes before broadcasting the request message
for the next event execution. Thus, delay at each node is cumulated among nodes. However, if each
node can execute several synchronization events asynchronously, the total transmission rate (achieved by
those events) could be improved.

Performance of more complicated distributed systems
Next, we have evaluated the performance in a mutual exclusion system where remote concurrent                                                                                                                   ƒ

processes use a resource exclusively as in Example 3 of Sect. 5. We show in Table 11 the experimental

result with several numbers for . Table 11 shows that the performance does not depend on the number

of user’s processes. This is owing to the property of our algorithm that each synchronization consisting
of  ƒ  processes is decided by
        Ò                          messages, independent of the number of all processes (here, the request
                                                    ƒ   Ò

messages sent for the unselected synchronizations will be used to decide the subsequent synchronizations
as long as their sender processes are not disabled).
    Finally, we estimate the performance of a duplication system explained in Sect. 5 using the above
results. In Example 1. of Sect. 5, first a task is simultaneously distributed to three identical processes
on different nodes, it is processed at each node, and then each calculation result is collected to a node.
Thus, the total transmission time per task can be denoted by                     3
                                                                                          where
                                                                                     ¢ j “ ˆ ’  g4
                                                                                                  5  tC¾G
                                                                                                     „ g Á  Ä       '@Dˆ
                                                                                                                     j  … Ž        2
                                                                                                                                    j “ ˆ ’  g
                                                                                                                                     ‚”ft6 
represents the time for transmitting
                                           to three nodes by multi-way synchronization, and
                                                                    “ ˆ ’
                                                                    ”f                                                          tg Á
                                                                                                                                   „      j  … Ž

for transmitting        „to one node. When multi-way synchronization is used for data transmission and
                                 … Ž
the sizes of       and
                “ ˆ ’
                ”6C          are KB, the total transmission duration is about 0.01*S seconds with the
                                    „        … Ž
                                            'VDˆ                e

result in Table 12 (packet size = 8KB).
    If we use peer-to-peer asynchronous communication of 1 MB/sec bandwidth for data transmission
and it works perfectly, we obtains the result of 0.006*S seconds.
    Although it depends on S and the processing time of each task, we think the above result enables the
generated prototype to be applied to practical use.

7           Conclusion
In this paper, we have proposed a technique to implement distributed systems using the LOTOS lan-
guage. In the proposed technique, we use multi-way synchronization to specify the interaction among
multiple nodes, and the whole system is implemented as a set of programs cooperating with each other
by exchanging messages.
    The main difference between our approach and the existing algorithms is that our approach assumes
a total order broadcast mechanism on target networks to simplify the implementation algorithm.
    Through the experiments on Ethernet LAN, we have shown that the programs generated from some
LOTOS specifications of practical distributed systems (e.g., duplication systems and mutual exclusion
systems) work as efficiently as they can be used as prototype implementation.
    Our implementation technique can also be used for the visualization of the system behavior. In [24],
we have proposed a visualization technique which enables real-time monitoring of dynamic behavior of
a system by graphical animation. Since such graphical animation requires a lot of machine resources
(e.g., processor power), it may be useful to apply the visualization technique to the distributed programs
of a system specification in order to keep the system from working inefficiently.
    Moreover, we think that the proposed LOTOS and synchronous communication based model is espe-
cially useful for development of multi-media systems. In [20], we have proposed a technique to flexibly
implement QoS control mechanisms into multi-media systems with the constraint oriented description
style of a time extension of LOTOS. Here, each QoS requirement (such as inter-media synchronization)
is considered as a constraint to behavior of media-object playbacks. Owing to multi-way synchroniza-
tion facility of LOTOS, we can develop each QoS control mechanism as an independent process and thus
easily integrate all/part of such mechanisms into the final code depending on user requirements, system
capability, and so on. Using this technique with the proposed synchronous communication model, we
will be able to provide network-level QoS control mechanisms easily since with multi-way synchroniza-
tion in the proposed model we can give constraints to communication among nodes for regulation of
transmission rate and so on, as shown in Sect. 5.

    In the proposed subclass of LOTOS, we assume that the system specification should be described as
the set of behaviors for all nodes. However, we can use the technique in [11] to obtain the set of internal
behaviors of nodes from a service specification (which describes the whole system behavior without the
notion of nodes).

 [1] Abe, K., Matsuura, T. and Taniguchi, K.: “An Implementation of Portable Lightweight Process
     Mechanism under BSD UNIX”, Journal of Information Processing Society of Japan, Vol. 36, No.
     2, pp.296-303 (1995) (in Japanese).
 [2] Bochmann, G. v., Gao, Q. and Wu, C.: “On the Distributed Implementation of LOTOS”, Proc. 2nd
     Intl. Conf. on Formal Description Techniques, pp. 133 – 146 (1989).
 [3] Cheng, Z., Huang, T., and Shiratori, N.: A New Distributed Algorithm for Implementation of
     LOTOS Multi-Rendezvous, Proc. 7th Intl. Conf. on Formal Description Techniques (FORTE’94),
     pp. 493 – 504 (1994).
 [4] Dubuis, E.: An Algorithm for Translating LOTOS Behavior Expressions into Automata and Ports,
     Proc. 2nd Formal Description Techniques (FORTE’89), pp. 163 – 177(1990).
 [5] Ehrig, H. and Mahr, B. : Fundamentals of Algebraic Specification 1, EATCS Monographs on The-
     oretical Computer Science, Vol. 6, Springer-Verlag (1985).
 [6] Gilbert, D.: Executable LOTOS: Using PARLOG to implement an FDT, Proc. 7th Protocol Speci-
     fication, Testing and Verification (PSTV-VII), pp. 281 – 294 (1987).
 [7] Higashino, T. and Taniguchi, K. : A System for the Refinements of Algebraic Specifications and
     their Efficient Executions, Proc. 24th Hawaii Intl. Conf. on System Sciences (HICCS-24), Vol. II,
 [8] Inoue, K., Seki, H., Taniguchi, K. and Kasami, T. : Compiling and Optimizing Methods for the
     Functional Language ASL/F, Science of Computer Programming, Vol. 7, No. 3, pp.297-312(1986).
 [9] ISO : LOTOS: A Formal Description Technique based on the Temporal Ordering of Observational
     Behaviour, ISO 8807(1989).
[10] ISO/IEC/TR 10167: Information Technology – Open Systems Interconnection – Guidelines for the
     application of Estelle, LOTOS and SDL (1991).
[11] Kant, C., Higashino, T. and Bochmann, G.v.: “Deriving protocol specifications from service speci-
     fications written in LOTOS”, Distributed Computing, Vol. 10, No. 1, pp. 29 – 47 (1996).
[12] Lamport, L.: “Time, Clocks, and the Ordering of Events in a Distributed System”, Communications
     of the ACM, Vol. 21, No. 7 (1978).
[13] Logrippo, L., Faci, M. and Haj-Hussein, M.: “An introduction to LOTOS: Learning by examples”,
     Computer Networks and ISDN Systems, 23 (5), pp. 325 – 342 (1992).
[14] Luan, S. and Gligor, V.D. : A Fault Tolerant Protocol for Atomic Broadcast, IEEE Trans. on Parallel
     and Distributed Systems, Vol. 1, No. 3, pp. 271 – 285 (1990).
[15] Manas, J. A., Salvachia, J.: : a Virtual LOTOS Machine, Proc. 4th Formal Description Tech-
     niques (FORTE’91), pp.445 – 460(1991).
[16] Melliar, P.M., Moser, L.E. and Agrawara, V.: Broadcast Protocols for Distributed Systems, IEEE
     Trans. on Parallel and Distributed Systems, Vol. 1, No. 1, pp. 17 – 25 (1990).

[17] Naik, K.: Distributed Implementation of Multi-rendezvous in LOTOS Using the Orthogonal
     Communication Structure in Linda, Proc. 15th Intl. Conf. on Distributed Computing Systems
     (ICDCS’95), pp. 518 – 525 (1995).
[18] Nomura, S., Hasegawa, T. and Takizuka, T. : A LOTOS Compiler and Process Synchronization
     Manager, Proc. 10th Intl. Symp. on Protocol Specification, Testing, and Verification (PSTV-X), pp.
     169 – 182 (1990).
[19] Sisto, R., Ciminiera, L. and Valenzano, A.: “A Protocol for Multi-rendezvous of LOTOS Pro-
     cesses”, IEEE Trans. on Computer, Vol. 40, No. 1, pp. 437 – 447 (1991).
[20] Terashima, Y., Yasumoto, K., Higashino, T., Abe, K., Matsuura, T. and Taniguchi, K. : “Integra-
     tion of QoS Guarantees into SMIL and its Flexible Implementation”, Proc. of 8th IFIP/IEEE Intl.
     Workshop on Quality of Service (IWQoS2000), pp. 164–166 (2000).
[21] Van Eijk, P., Kremer, H. and Van Sinderen, M.: On the use of specification styles for automated pro-
     tocol implementation from LOTOS to C, Proc. 10th Protocol Specification, Testing and Verification
     (PSTV-X), pp.157 – 168(1990).
[22] Vissers, C. A., Scollo, G. and Sinderen, M. v.: Architecture and Specification Style in Formal
     Descriptions of Distributed Systems, Proc. the 8th Intl. Symp. on Protocol Specification, Testing,
     and Verification(PSTV-VIII), pp. 189-204 (1988).
[23] Yasumoto, K., Higashino, T., Abe, K., Matsuura, T. and Taniguchi, K.: A LOTOS Compiler Gen-
     erating Multi-threaded Object Codes, Proc. 8th Formal Description Techniques (FORTE’95), pp.
     271 – 286 (1995).
[24] Yasumoto, K., Higashino, T., Matsuura, T. and Taniguchi, K.: “Protocol Visualization using LO-
     TOS Multi-Rendezvous Mechanism ”, Proc. IEEE 1995 Intl. Conf. on Network Protocols (ICNP-
     95), pp. 118 – 125 (1995).
[25] Yasumoto, K., Gotoh, K., Tatsumoto, H., Higashino, T. and Taniguchi, K.: Implementation of
     Distributed Systems described with LOTOS Multi-rendezvous on Bus Topology Networks, Proc.
     Joint Intl. Conf. on 10th Formal Description Techniques and 17th Protocol Specification, Testing
     and Verification (FORTE/PSTV’97), pp. 161 – 176 (1997).


To top