ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button
Article:
  10 Reasons We Need Java 3.0
Subject:   Yes - clean up thread locks
Date:   2002-08-06 08:56:03
From:   wmshub
I agree 100% with your comments on locks. Java's "every object is a synchronization point" is stupid; if there were one object, the "Monitor" object, that could be synchronized on, then you could add it to any object that you want to use, so what's the benefit of having all objects be synchronization points? The problem is often that when I need to synchnronize, what object do I use? There's no way to be sure.


In addition, it is a realy problem that you can't extend/modify the locks. In C, I have a library+macro system wrapping the pthreads that lets me force lock ordering; when I grab locks out of order, it immediately throws an assertion. To do this in java, I need to invent my own locks, that have explicit "lock()" and "unlock()" calls, thus losing the one good thing that java locks have (you can't forgot to unlock a java lock). It would be so nice to have both, "synchronized(lock) { ... }" while at the same time being able to override locking semantics to add checks for lock ordering, etc.