Post by WLadPost by Craig CareyI see that Zonnon was not really offering new and major improvements
to Oberon.
At first I guess you didn't even read any doc devoted Zonnon.
FIRST OF ALL - ACTIVE OBJECTS
This is not yet one "multitasking features -> objects" BUT "objects
-> multitasking". That is at Active Oberon and Zonnon we can see not
just another attempt to express "processes", "threads", "semaphores",
"locks" and other multitasking trumpery through objects! But quite the
contrary! We get features to build active structures, where "processes"
ARE result of cooperation of such structures. I think such way is more
natural to model things of real world...
activities
exclusive blocks
awaits
channels (and corresponding operations)
syntax specification of a communication protocol in EBNF (between
object activities)
And after all these you can say: "I see that Zonnon was not really
offering new and major improvements to Oberon."? :o)))))
I think these features are new and major improvements not only to
Oberon... :o)
I used the words "not really". I assume people are not going to use
Zonnon and I am not sure, but is that the Swiss government writing
Zonnon, or some university students?.
The improvment might have considered already by the Ada language
authority (ARG). All 5 of the e-mails gunning out the mistake that
was made in Java (similarly Zonnon) are copied in below for the
pleasure of the readers.
|
| Date: Sun, 09 Jun 2002 09:16:42 -0400
| From: Tucker Taft <***@avercom.net>
| To: Ada-Comment List <ada-***@ada-auth.org>
| List-Server: DOLIST Server Custom 3.4 B2110
| List-Help: <mailto:***@ada-auth.org?body=help%20ada-comment>
| Subject: Re: [Ada-Comment] Language extension proposals (Non API).
|
| An important principle of the protected type is that
| all synchronization associated with a given set of
| data is gathered into a single module. This is the
| so-called "monitor" concept introduced many many years
| ago, to almost universal acclaim. It dramatically
| improves the structuring of multi-tasking systems,
| in my view.
|
| Also in my view, Java's "synchronized" blocks are a real
| step backward. They approximate your suggestion, though
| as Ted Baker points out, they have an associated object,
| which is critical. Java has synchronized methods, which
| are associated with the enclosing class (or an instance
| thereof), but Java's synchronized blocks can be scattered
| anywhere, with no modularity whatsoever, and no scoping
| relation to the associated object. This makes any kind
| of analysis of potential deadlocks and race conditions
| much more difficult.
|
| -Tucker Taft ***@yaletaft.com
|
| Robin P. Reagan <***@reagans.org> wrote:
| >
| > Ada community,
| >
| > I would like to propose the addition of a protected block to the Ada
| > language standard. Like a protected object, a protected block would
| > allow the sequence of statements to be executed atomically without the
| > overhead of a separate object.
| > This would allow an uninterruptable (atomic) sequence of statements to
| > be executed without the OS context switching or responding to
| > interrupts. This construct is meant to be used as a means of accessing
| > hardware in an uninterruptable fashion without the overhead of a
| > separately declared protected object. This could be accomplished using
| > dynamic priorities, but I think a language specified construct would be
| > more portable and easier to read.
| >
| > ex:
| >
| > begin -- procedure, function, block ...
| >
| > declare protected
| > -- Implied declaration
| > -- pragma priority( System.Any_Priority'last );
| > begin
| > -- process hw access statements atomically.
| > end; -- protected block.
| >
| > end; -- procedure, function, block ...
| >
|
-------------------------------------------------------------------------
At 2002-05-25 17:55 -0400 Saturday, Ted Baker <***@cs.fsu.edu> wrote:
| The proposed construct would be dangerously confusing, because:
|
| 1) Because of the similar keyword to protected objects, people
| are likely to think it is related to a protected operation,
| but it cannot be, because:
|
| 2) It lacks an associated object or other means to specify the other blocks
| with respect to which mutual exclusion required. Such specification
| is necessary if you are going to provide any kind of guaranteed
| mutual exclusion, because:
|
| 3) Priority alone does not guarantee there will be no interleaved
| or parallel (multi-cpu) execution of other similarly protected blocks.
|
| Depending on what you really want, there seem to be two reasonable
| alternative proposals possible:
|
| A) Something we considered in the Ada 9X process as an alternative
| to the current protected objects, e.g., a special lock object.
|
| mylock : Protection (System.Any_Priority'last);
| ...
|
| declare
| protected mylock
| begin
| -- process hw access statements atomically.
| end mylock;
|
| This provides mutual exclusion and all the other semantics of
| protected objects (priority, atc protection). It does not seem
| there should be any huge challenge to implement it, since it
| amounts (more or less) to a protected object with anonymout
| in-line procedures.
|
| B) If you just want the priority effect, without mutual exclusion
| and protection from ATC, then the syntax should spell it out,
| e.g., a pragma
|
| declare
| pragma Priority (System.Any_Priority'last);
| begin
| ...
| end;
|
| --Ted Baker
| .
-------------------------------------------------------------------------
At 2002-06-09 09:27 -0400 Sunday, Robert Dewar wrote:
| > > begin -- procedure, function, block ...
| > >
| > > declare protected
| > > -- Implied declaration
| > > -- pragma priority( System.Any_Priority'last );
| > > begin
| > > -- process hw access statements atomically.
| > > end; -- protected block.
| > >
| > > end; -- procedure, function, block ...
|
| One important aspect of protected operations is that abort is deferred. Since
| Ada 95 (very foolishly in my opinon :-) made abort a first class citizen by
| the introduction of asynchronous transfer of control, all code has to worry
| about being aborted.
|
| It is quite hard work to make stuff safe with respect to abort. For example,
| if you have an in place sort that works with exchanges, and you want the
| sort to be safe from abort in the sense that if an abort occurs, you want
| the data intact, just possibly not sorted yet.
|
| This means that the exchange has to be protected from abort. There is no nice
| way in the language to do this right now. The two tecniques are to introduce
| a protected type, or to do the exchange in a dummy finalization routine.
| Both of these solutions are really heavy and ugly.
|
| In GNAT, we have introduced pragma Abort_Defer to respond to this need, but
| the above proposal would also solve this. Nevertheless I agree with Tuck
| that it is certainly open to serious abuse.
|
-------------------------------------------------------------------------
At 2002-06-09 21:33 +0200 Sunday, Michael Erdmann <***@snafu.de> wrote:
| Tucker Taft wrote:
|
| >An important principle of the protected type is that
...
| >of analysis of potential deadlocks and race conditions
| >much more difficult.
| >
| I guess this feature may makes sense when you have to control external
| hardware, e.g. if you are doing polling for some reason and you want
| to avoid beeing interrupted while your polling loop run. In such a case
| the overhead of declaring a protected type which represents the
| external hardware i some way can be to costly.
| But i am not sure if this rare problem should be handled in the
| language, since this problem could be solved by an extension
| of RM C.3, which does not provide a way to mask off interrupt
| of a certain priority.
|
| The feature makes no sense when you intend to protect data, for this
| purpose protected types are available.
|
-------------------------------------------------------------------------
(The Ada-Comment messages are edited a lot and then archived at
the AIS_REST.ZIP file that is linked to from an 'Issues' page at this
website: http://www.ada-auth.org/ )
I found some Zonnon syntax that shows that there is blocking
BEGIN-END blocks:
http://zonnon.ethz.ch/papers/Zonnon_Syntax_Final_Comments.pdf
(extracted from the Russian text)
-------------------------------------------------------------
BlockStatement = BEGIN [ BlockModifiers ]
StatementSequence
{ ExcHandler }
[ CommonExcHandler ]
END
BlockModifiers =
"{" Ident { "," Ident } "}". // ACTIVE or EXCLUSIVE
Statement = [ Assignment
| ProcedureCall
| IfStatement
| CaseStatement
| WhileStatement
| RepeatStatement
| LoopStatement
| ForStatement
| EXIT
| RETURN [ Expression ]
| BlockStatement ]
StatementSequence = Statement { ";" Statement }
-------------------------------------------------------------
The Ada 95 Annotated Reference Manual part on Protected objects:
http://www.adaic.org/standards/95aarm/html/AA-9-4.html
----
Creating threads isn't. Here is a Zonnon example:
http://zonnon.ethz.ch/ZonnonTestSuite/11_Activities_Behavior_And_Interaction/T01-x.znn.html
-------------------------------------------------------------------------
DEFINITION TALKPARTICIPANT;
ACTIVITY TALK;
(* THE SIMPLEST TALKING PROTOCOL BETWEEN SENDER AND RECEIVER. *)
TYPE { TALK = { INTEGER ?INTEGER }. }.
END TALK;
END TALKPARTICIPANT
...
RECEIVING := NEW RECEIVER.RECEIVING; (* CREATE RECEIVING
ACTIVITY INSTANCE FOR THE OBJECT. *)
-------------------------------------------------------------------------
What is that "?" is inside of that activity ?. At least in Ada 95, the
familiar procedure syntax is reused for the protected objects.
Procedure calls are fast. The protected objects are not instanteous
to get through, with the reevaluating of the barriers as non-global
varables change. Having them conspicuous (and not nested is OK).
Zonnon lacks the equivalent of guards blocking tasks ??.
---
Can Zonnon allow a program to excecute a background task?. In Ada I'd
have a protected object implement a (maybe-multiway) flip-flop. I'd
code up the barrier expression.
I have not got time to understand Zonnon.
Here is an example of what Zonnon might not be able to handle well but
Ada could easily:
A call to a task (thread) can be accepted and examined and then
requeued and parked onto a protected object inside of the task, or
sent back to the same task. An aim is to avoid accepting the callers
procedure parameters and putting them onto a queue since:
* then the caller would be unblocked
* the task can't later raise an exception and cause the caller to
drop out to the nearest exception handler of a begin-end block
* in done differently, then Ada 95 will manage the queue containing
parameters of calling tasks (indifferently onto a task or
protected object)
Though that is an argument for the requeue statement, it can be
replaced with the entry_index (of RM95 9.5.2) (a 2nd parameter list,
that is 1 parameter long).
I searched a Google's domain on [ "ada 95" oberon ethz.ch ] and found
little. About 2 e-mails only since since 1999 matching, though there
are more that are older.
Here is that other Usenet message:
http://groups.google.com/groups?selm=mailman.1041721989.14159.comp.lang.ada%40ada.eu.org
| From: "Robert C. Leif" <rleif-@-rleif.com>
| Newsgroups: comp.lang.ada
| Subject: RE: advantages or disadvantages of ADA over pascal or modula
| Date: Sat, 4 Jan 2003 15:12:39 -0800
| List-Subscribe: <http://ada.eu.org/mailman/listinfo/comp.lang.ada>,
|
|
| To be fair, Ada should be compared to Wirth's latest creation, Oberon.
| Oberon is available as a .NET compiler. While the Ada community has
| talked
| incessantly about writing an operating system, Wirth and Gutknecht did.
| Oberon and its operating system are described in Project Oberon,
| Addison-Wesley ACM Press ISBN 0-201-54428-8. http://www.oberon.ethz.ch/.
| Some of the Oberon software could be translated into Ada.
| Bob Leif
|
| -----Original Message-----
| From: comp.lang.ada-admin-@-ada.eu.org
| [mailto:comp.lang.ada-admin-@-ada.eu.org]
| On Behalf Of Adrian Knoth
| Sent: Friday, January 03, 2003 6:36 PM
| To: comp.lang.ada-@-ada.eu.org
| Subject: Re: advantages or disadvantages of ADA over pascal or modula
|
| karl bowl <karl.bowl-@-gmx.de> wrote:
|
| > I would like to ask anybody to tell me about advantages or
| disadvantages
| of
| > ADA(95) over pascal or modula(2).
|
| Pascal is mainly for learning purpose. Modula-(3) is a successor of
| Pascal, so the properties are similar.
|
| Ada95 (watch the spelling) looks like a Pascal-alike language but is
| not the 7th million ugly language from N. Wirth :)
|
| Ada is one of the clearest, most consequent languages at all, it
| focusses on readability, portability and security. The last fact
| is important. By detecting the maximum of errors at compile-time
| running the program is improved right from the beginning. And even
| at runtime, a lot of checks guarantee you the right result of
| operations, so limiting the amount of surprises.
|
| There was an article about Ada and an Australian satellite some weeks
| ago, you should read it. It clearly states why Ada was used, because
| there is no possibility to reset the computer in space.
|
| And a common joke in language-discussion is that C++-programmers should
| go on debugging while the Ada-programmers have spare time. This is
| because
| if Ada-code compiles it is less buggy than other.
|
| I've done all, Pascal, Ada and Modula. You have a lot limitations in
| Pascal. You have identical limitations in Modula, but Modula is better
| in some cases than Pascal. At least, the PM3-compiler is bad. I've
| found two serious bugs in the P-Modula3-compiler within the first two
| weeksof use and several other bugs afterwards. There are even error
| in the documentation, the runtime-environment and, worst, in the
| implementation of the language definition.
|
| Ada has a widely discussed language definition and compilers are forced
| to it in order to call itself an Ada-compiler. There are some features
| that are COULDs, that's for sure.
|
| With Ada95 you have the power of a well-designed modern language with
| (parallel-)tasking-capabilities, OOP, security and so on. I guess you
| won't miss anything if you're used to Pascal-alike languages.
|
| P.S.: By posting with gmx.de, do you know toh?
|
| --
| mail: adi-@-thur.de http://adi.thur.de/ PGP: v2-key via keyserver
For satellites running GNAT RTEMS Ada, the CPU speeds can be 16 MHz.
-- Craig Carey,
Ada mailing lists: http://www.ijs.co.nz/ada_95.htm