From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,52fd60a337c05842 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-16 08:07:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-out.nuthinbutnews.com!propagator-sterling!news-in.nuthinbutnews.com!cyclone1.gnilink.net!wn3feed!worldnet.att.net!bgtnsc05-news.ops.worldnet.att.net.POSTED!not-for-mail Message-ID: <3D0CA980.5050505@worldnet.att.net> From: Jim Rogers User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: ada paper critic References: <8avjgu8bnkifee01ffu5i4h247n3khl7ub@4ax.com> <3D0A075F.482703FE@san.rr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 16 Jun 2002 15:07:03 GMT NNTP-Posting-Host: 12.86.34.161 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1024240023 12.86.34.161 (Sun, 16 Jun 2002 15:07:03 GMT) NNTP-Posting-Date: Sun, 16 Jun 2002 15:07:03 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:26079 Date: 2002-06-16T15:07:03+00:00 List-Id: > 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