Re: ada paper critic

[Jim Rogers <jimmaureenrogers@worldnet.att.net>]

> Darren New wrote:
> 
> 
>>"Dmitry A. Kazakov" wrote:
>>
>>>Actually I meant Ada's protected objects and not the visibility rules.
>>>There is a great need to have protected objects extensible (tagged).
>>>At the same time it is not very clear (at least to me), how to do it.
>>>
>>What's wrong with Java's approach to OO threading and protected objects?
>>


There are actually a number of problems with Java's approach to OO
threading and protected objects.

The first problem is that Java does not have protected objects in the
Ada sense of the term. Java only provides synchronization blocks, which
are not even close to being protected objects.

Java's threading model works very well as long as your threads do not
communicate with each other, and they never need to be terminated.
Of course, many useful concurrent designs do need to have
communication between tasks, and those tasks need to be terminated
as some point in the program.

The only safe communication feature for Java threads is synchronized
blocks. The code in the synchronized block belongs to the shared
object. That object might be one of the threads, or a shared object.

Let's look at a classical concurrent design, the producer/consumer
model. Any decent threading implementation should be able to
properly support a producer/consumer model. Let's assume that our
application needs reliable communication between the producer thread
and the consumer thread. We will use a bounded queue between the
producer and the consumer. The producer must not write to the bounded
queue when it is full, and the consumer must not read from the
bounded queue when it is empty. In Ada this would be handled simply
using a protected object with two entries; one to add elements to
the bounded queue, and one to extract elements from the bounded queue.

In Java you will create your bounded queue class. You will provide two
methods, one to add elements to the queue and one to extract elements
from the queue. Each of these methods must be declared synchronized.

Under Java rules you must call the synchronized block, and obtain the
synchronization lock before you can check for conditions such as
queue full or queue empty. If the producer is calling the add element
method and the queue is full the wait() method must be called to
suspend the producer. Note that the producer class has no control
over this code. It merely calls the method defined in the bounded
queue class. There is no Java equivalent to the Ada timed select
statement allowing an Ada task to limit its suspension time on an
entry call. In Java the producer will be suspended until another
thread, in this case the consumer, calls the notify() or the
notifyAll() method. The notify() method randomly unsuspends one
suspended thread, no matter which synchronization block it is waiting
for. The notifyAll() method unsuspends all suspended threads, forcing
each to check whether or not it should proceed. If not, it must be
immediately re-suspended using a wait() call.

Note that all this re-checking and waiting is still occuring in the
code for the synchronized object, not at all under control of the
producer thread. How do we design this so that the producer can
have an effective timeout on its suspension? We could design the
bounded queue code so that it provides a fixed timeout period for
all threads that may be suspended. The problem here is that this
forces all threads calling this synchronized block to have
the same timing requirements. You could allow the calling thread
to pass a timeout value to the synchronized block. This forces you
to reveal internal state of your thread to another object, violating
encapsulation principles.

Given the behavior of the notify() and the notifyAll() methods there
is no guarantee that a given thread will ever progress past a set
of wait/notify calls to execute the bulk of the synchronized block.
Java provides nothing like an Ada entry queue. Thus, the order in
which threads are unsuspended is not deterministic.

Let's turn now to the issue of terminating a thread. Java provides a
stop() method to terminate a thread. Java has also deprecated the
use of this method because it has been found to be unsafe. The
problem is that the stop() method does not release any synchronization
locks currently held by the thread being stopped. This easily
results in starvation because no other thread will be allowed to
acquire the synchronization lock. The current Java solution is to
require the programmer to invent his own termination method which
some other method will call. Of course, that termination condition
will not be serviced until the "terminated" thread has returned from
all synchronized blocks, which as I have shown above, may never
happen.

Jim Rogers