MSC-News: Threads of Control

Subject: MSC-News: Threads of Control
From: Oystein Haugen (
Date: Thu Aug 21 1997 - 07:50:58 GMT

The originator of this message is responsible for its content.
-----From Oystein Haugen <> to mscnews -----

Ekkart and rest of MSC friends

The distributed suggestion for describing threads of control is
interesting, but we should be careful about _what_ we want to describe.
The concept of "thread of control" is new to MSC. MSC-96 describes a set
of interacting, parallel instances. It is true that some "threads" or
"traces" are legal sequences of events while others are excluded by any
given description. What then is a "thread of control"?

If the basic model is the execution of a C++ program, the situation is
different. A C++ execution can be seen as a thread of control through
the set of objects of which member functions are executed.

If the basic model is an SDL system execution, where the processes also
apply remote procedures, this is something in between the two models
sketched above, and this is the situation I believe we want to describe
in MSC-2000. When a process A calls a remote procedure P in process B,
process A will not consume any other signals until the return of P.
Neither will process A continue to do anything else; process A will just

Looking at the UML notation in "Sequence Diagrams" which intends to
describe "thread of control" (UML 1.0 Notation Guide p 66+) it seems
that the special notation (rectangle on instance axis) describes the
existence of the procedure. This means that the fact that the _caller_
is not allowed to do anything is not shown at all! What is shown is the
procedure stack. The question is whether this is what we want/need.

If we had had a notation on the other side at the remote procedure
caller, it could serve as supporting a syntactic requirement that no
events can take place within it.

For remote procedures it seems at least reasonable to have a
message-like notation describing the calling of the procedure and the
return of the procedure. There should be some way to distinguish these
messages from normal asynchronous messages.

One suggestion, which is very minimum, could be the following:
1. Calling a remote procedure P: from instance A to instance B make a
message with the text "remote P(parameters)" (remote is a new keyword)
2. Returning from a remoter procedure P: from instance B to instance A
make a message with the text "return P(parameters)" (return is a new
3. There is a syntactic restriction that no events can take place on A
when the number of remote output is greater than the number of remote

I believe all the semantics is in here, but the diagrams may not be as
readable as desired. Therefore more syntactic sugar may be attractive.


Oystein Haugen, Ericsson as. , P.O. box 34, N-1361 Billingstad, Norway
Tel: +47 66 84 23 46 Fax: +47 66 98 28 20 E-mail:

-----End text from Oystein Haugen <> to mscnews ----- For help, email "" with the body of your email as: help or (iff this does not answer your question) email:

This archive was generated by hypermail 2a23 : Wed Jun 19 2013 - 13:16:37 GMT