>> If you need to do I/O with mutual exclusion, then an Ada 83-style
>> "passive task" will work fine. Presumably if you are doing I/O
>> then the overhead of passive tasks versus protected objects
>> will not be an issue.
>Well, of course we could use passive tasks. But tasks in Ada
>are _syntactically_ quite "heavy" for this purpose, and they
>are, for this reason, potentially a turnoff compared to the
>syntactic simplicity of protected types and the (apparent)
>simplicity of synchronized methods in Java, which is where this
>thread started. Tucker recommended P.T.s as an equivalent,
>but for many uses, they are not equivalent!
The "simplicity" of Java synchronized methods is deceptive.
See comments below.
>> >Also, because only an _object_ (never a type) can be declared in the
>> >private part of a protected type/object, one sometimes must resort
>> >to contorted code to provide a place where that type can be declared
>> >without making it too public.
>> There are times when you need to declare an array type outside
>> the protected object/type, but I think "contorted" is a bit of an
>> exaggeration. Maybe Ada '0Y will allow "anonymous arrays"
>> to be components of records and protected objects :-)
>> ... [snipping joke about Bill Gates]...
>It was never clear to me why type declarations aren;t allowed in
>the private part of a P.T. They are purely compilation-time
>things and would not increase the execution overhead. What's
>the rationale for excluding them?
It's not an execution-time issue; the reason is the semantic complexity
of dealing with a type declared in an object or in a type. Indeed,
that was the reason that anonymous arrays in records were dropped
from the Green language when it was fetal Ada.
>> >Protected types in Ada are a bit schizophrenic - on the one hand,
>> >they provide some very nice abstraction, but they are, I think,
>> >so compromised by efficient-implementation concerns that they
>> >take away with the left hand what they give with the right.
>> Well efficiency was really the main objective here. If you don't need
>> the performance benefit, then use Ada 83 passive tasks.
>Well, yes, you are giving a nice statement of the party line on
It's more than the party line. If protected objects did not offer
better performance than passive tasks, they probably would not have
been approved by the Ada 9X reviewers.
>What are the restrictions on Java synchonized methods?
>Is there anything in the Java RM equivalent to the "bounded error"
>fine print in the Ada RM? If not, then the two are not equivalent!
There are no such restrictions, and that is exactly the problem. If
a synchronized method blocks (say by executing sleep(), or maybe
indirectly by doing an I/O call) then the calling thread
releases the lock, and there goes mutual exclusion. The Java
spec's silence on this issue does not mean that the construct
is simple or safe to use.
There are other problems with synchronized methods, and
many areas where Ada's protected objects/types are better.
Tucker mentioned one (the fact that a method is synchronized
does not mean that the object is always accessed mutually
exclusively, since there also may be other non-synchronized
methods on the same object). Here are some others:
* Mutual calls across synchronized methods from two objects
will deadlock. Ada's Ceiling_Priority avoids this problem.
* It is a (subtle) error for a synchronized instance method to
make a non-synchronized access to a static entity. That is,
there are separate locks for the instance and the class objects.
* It is not always obvious whether to make a method synchronized.
* Ada distinguishes protected entries from protected procedures,
thus making it explicit when queuing (and not simply object locking)
* Protected functions in Ada may be invoked with true concurrency
in a multiprocessor environment. Java lacks an equivalent facility
* In Ada, protected entries combine a condition test with object locking
in a way that avoids race conditions. In Java, the programmer must
explicitly code the condition wait/notification logic, a more error-prone
>We should not glibly recommended Ada construct
>X as equivalent to Java construct Y unless they are really
>equivalent, especially if the goal is to convince people like
I don't think that the claim was for exact equivalence of the
constructs. Both are designed to meet similar goals, viz.
mutual exclusion, but have different rules, different styles,
different performance, and different degrees of safety /
maintainability. I think Ada is almost uniformly better
than Java in these areas. If you're not convinced, come
to my talk at SIGAda '98. (Blatant ad for the conference:
check out the http://www.acm.org/sigada/conf/sa98/
>Oh - please put your papers online as soon as you can. If it's
>a question of time/resources, I can get someone here to do it.
The problem is that my original on-line version got lost when
my laptop was stolen last November. (If the person who stole
the machine is a subscriber to this group, please return the
file, and I won't ask any questions :-) The text is being re-entered,
and I hope to have it available by the end of next week.