Re: [9fans] Re: advantages of limbo

[rog@vitanuova.com]

> 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.