Fri, 17 Jul 1998 11:41:15 -0700
Mike Brenner's original comment:
MB>> > However, Ada has the disadvantage of not having synchronized methods.
>> Ada's protected subprograms are essentially identical to synchronized
>> However, protected subprograms come with the added safety that a
>> protected object is fully encapsulated by protected subprograms,
>> whereas in Java there is nothing precluding someone from adding an
>> unsynchronized method by mistake and thereby destroying the nicely
>> synchronized access.
>> Note that in the Ada to Java compilers, Ada's protected subprograms
>> are implemented using synchronized methods, because they have
>> such nearly identical semantics.
Mike Feldman's response:
>How does this square with the fine print in the RM (9.7.1(8)) to the
>effect that invoking a potentially blocking operation in a protected
>subprogram is a bounded error? Since one is not really supposed to
>write code whose execution is bounded-erroneous, this means that
>e.g. one cannot enclose an I/O call in a protected subprogram to
>get a synchronized I/O call, because I/O calls are (mostly)
>potentially blocking. Yet I/O calls are precisely the kind of thing
>one would like to protect.
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.
>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 :-)
(This is a smiley because it is doubtful that the benefit is worth the
price. OTOH if Bill Gates comes to SIGAda '98 and tells us
that the inclusion of this feature would convince MicroSoft
to move to Ada, then perhaps WG9 would buy that argument :-)
>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.