From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: advantages of limbo From: rog@vitanuova.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Tue, 2 Mar 2004 15:03:12 +0000 Topicbox-Message-UUID: 0cd81350-eacd-11e9-9e20-41e7f4b1d025 > Class Thread is not a part of the language. 'synchronized' > is. What's wrong with Java synchronization? Can you please > bring an example in Java and limbo where Java's synchronization > is bad while limbo's approach is right? a selection from Allen Holub's "Taming Java Threads": : The "synchronised" keyword has several flaws: : : 1. You cannot specify a timeout value. : 2. You cannot interrupt a thread that is waiting to acquire a lock. : 3. You cannot safely acquire multiple locks. : [...] : : The wait()/notify() system also has problems: : 1. There is no way to detect whether wait() has returned normally : or because of a timeout. : 2. There is no way to implement a traditional condition variable : that remains in a "signalled" state. : 3. Nested-monitor lockout can happen too easily. : : [...] : : More facilities should be added to the language to support inter-thread : communication. Right now, the PipedInputStream and PipedOutputStream : classes can be used for this purpose, but they are much too inefficient for : most applications. : : [...] : : Access to partially constructed objects should be illegal. : The JLS currently permits access to a partially constructed object. : For example, a thread created within a constructor can access the object : being constructed, even though that object might not be fully : constructed. : : [...] : : The lack of good access control makes threading more : difficult than necessary. Often, methods don't have to : be thread safe if you can guarantee that they be called : only from synchronised subsystems. : : [...] : : The notion of immutability [...] is invaluable in multithreaded : situations since read-only access to immutable objects doesn't : have to be synchronised. Java's implementation of immutability : isn't tight enough for two reasons: : : 1. It is possible for an immutable object to be accessed before it's : fully created and this access might yield an incorrect value : for some field. : 2. The definition of immutable [...] is too loose: Objects addressed by : final references can indeed change state, even though the reference : itself cannot change state. : : [...] : : There is also the problem that both class-level (static) and instance (non-static) : methods can directly access class-level (static) fields. This access is : dangerous because synchronising the instance method doesn't : grab the class-level lock, so a synchronised static method can : access the class field at the same time as a synchronised instance : method. : : [...] : : The singleton-destruction problem discussed in Chapter 7 is a serious one. : [in chapter 7:] : There is a serious impediment to the correct implementation of Singleton: : How do you get rid of the thing? The Singleton object is created on : first use, but what if global resources like temporary files or database : connections are created by the Singleton's constructor? How do you : get rid of the temporary file or close the database connection in an : orderly way? [...] Though I hate to end this section on a pessimistic note, : I don't have an ideal solution to this problem. If you do, please write to me. : : [...] : : Daemon threads are shut down abruptly when all the non-daemon : threads terminate. This is a problen when the daemon has created : some sort of global resource (such as a database connection or a temporary : file), but hasn't closed or destroyed that resource when it is terminated. : : [...] : : The suspend() and resume() methods should just be put back into : Java. They're useful, and I don't like being treated like a kindergartener: : Removing them simply because they are potentially dangerous - a thread : can be holding a lock when suspended - is insulting. Let me decide : whether or not I want to use them. : : [...] : : You should be able to interrupt any blocking operation, not just : wait() and sleep(). [...] Right now, the only way to interrupt a blocking : I/O operation on a socket is to close the socket, and there's no : way to interrupt a blocking I/O operation on a file. with all of these issues, Limbo either ducks the issue (by not pretending to solve a problem it can't solve properly) or does things right.