Subject: SDL-News: RE: SDL Questions from M T Chan
From: M T Chan (csmtchan#cityu.edu.hk)
Date: Mon Nov 17 1997 - 08:37:41 GMT
The originator of this message is responsible for its content.
-----From M T Chan <csmtchan#cityu.edu.hk> to sdlnews -----
----------
From: Rick Reed TSE
Sent: Monday, 17 November, 1997 2:54 AM
To: sdlnews#sdl-forum.org; M T Chan
Subject: SDL-news: Reply to M T Chan
The originator of this message is responsible for its content.
-----From Rick Reed TSE <rickreed#tseng.co.uk> to sdlnews -----
I hope that Mr. Chan receives some alternative replies, but here is my
contribution.
>2. Is there any discussion about the pros and cons of using ACT-ONE
>and ASN.1 ? With respect to Rick Reed's recent mail re : Lutterwork
>Q.6/10 meeting results, there mentioned about the start of revision of the
>data model, what will be the direction of revision ? e.g. towards a total
>object orientation ?
The sdlnews#sdl-forum.org exploder is (in my opinion) the correct place for
this discussion. The first part of the exercise is have the discussion to
determine the direction of the revision. The associate rapporteur for this
work is Thomas Weigert <weigert#comm.mot.com>. However, from discussions to
date it seems to me that:
a) (from the user point of view) the ACT ONE model will be dropped;
b) "object orientation" will be more consistent throughout SDL;
c) there is a significent body of users that need ASN.1 support.
A good contribution to the discussion would be if Mr. Chan could explain
what he envisages "a total object orientation" would be in the context of
SDL data.
A "total" object orientation may be a bit exagerrated, however, what I mean is support of all currently prevailing OO concepts such as encapuslation with data attributes and methods, inheritance, overloading and specialization. In ACT ONE, most of the concepts are supported except specialization of operators (operator can be excluded from inheritance and adding a new one with the same name, but not inherited from a "super" operator type with redefinition). In ASN.1 only the data part can be defined and operator definition is not supported. In this aspect, I found the ADT approach of ACT ONE is more powerful by allowing users to define whatever operator they like.
>3. Is there any way to model threads ? i.e. concurrency with total
>shared memory variables
a) processes are very good for modelling threads;
Symmetric multiprocessor systems are becoming more common and one would wish to model this explicitly in system design. Shared memory access definitely has much less overhead compared to remote procedure call, it could be argued SDL is a specification language and should not concern about implementaion issue. In this aspect, processes and threads are quite different. Services should be a good model for threads if execution is not restricted to interleaving only. Signal exchange can be used to perform synchronization.
>4. We wish to model concurrency within operators of datatypes and
>propose the following :-
>
>newtype a
> literals;
*********there appears to be some literals missing here******
> operators
> op1 : a,b -> c;
> operator op1 referenced;
>endnewtype a;
>operator op1; fpar x a, y b; returns v c;
> start;
> task v := call remote-proc(x,y);
************a procedure cannot be called here************
******* a name cannot contain a "-", an underline is OK ********
>endoperator op1;
>In some process specification, there exists :
>
>exported procedure remote-proc; fpar x a. y b; returns v c;
************* syntax error " x a. " should be "x a, ".
> start;
> create process1;
> create process2; /* etc. handling the operator's detail actions */
> --
> --
> return v;
>endprocedure remote-proc;
*** it is not clear why this procedure should launch two other processes.
*** I can only assume that process1 and process2 should each proceed in
*** parallel and then reply with messages (say m1 and m2) to the process
*** for remote_proc, and there is a synchronization of the results in
*** remote_proc waiting for both m1 and m2.
My intention is to model parallel implementation of an operation e.g. a compression algorithm executed by more than one processes. The detail synchronization is exactly what you have pointed out.
>The application of operator op1 will be within a process which has an
>import of remote-proc.
It is not clear why you do not replace "op1(x,y)" with "CALL remote_proc(x,y)"?
In the system I am working on, I would like to distinguish two groups of users : e.g. application developers who will work on only data types and operators in a straight forward, normal programming language way. All remote/distributed accesses and concurrency will be hidden from them while the other group of users can be regarded as system implementor who will define, specify and provide the relevant data types to the application users. I guess I need to figure out another way to do this as procedure call is not allowed inside an operator definition.
Best regards.
M T Chan
Department of Computer Science
City University of Hong Kong
Tel : (852) 2 788 8621
Fax : (852) 2 788 8614
Room Y6413 Academic Building
-----End text from M T Chan <csmtchan#cityu.edu.hk> to sdlnews -----
For help, email "majordomo#sdl-forum.org" with the body of your email as:
help
or (iff this does not answer your question) email: owner-sdlnews#sdl-forum.org
This archive was generated by hypermail 2a23 : Sun Jun 16 2013 - 10:41:40 GMT