'own monitor' or 'own lock'?

Question

Dear,
I am writing about basics of threads, but at one moment I become confused. At some books I saw "own monitor" and some "own lock". I though that
"Thread owns monitor."
is the same as
"Thread owns lock."
actually, monitor is something what was used before, but now thats are locks, but people still say "monitor". I didn't find some part which makes it, at least to me, clear.
Is that true or it is not, in that case, what is real truth?
I read
http://java.sun.com/docs/books/jls/third_edition/html/memory.html
"Thinking in Java 3rd edition", Bruce Eckel
Also, look at next situtaion
public synchronized void a(){
  wait();
public synchronized void b(){
  a();
}If thread starts b(), counter of locks will become 1; when starts a() counter will become 2. When calls wait(), lock (or monitor?) will be completely realised. When it got notify() and re-own lock, it will get out of the wait set (suppose in the wait set is only that thread) and number of locks (counter) will be restored to value which was before thread goes to wait set. Where JVM keeps value of counter when thread is in the wait set? Actually, where JVM keeps number 2, in this example?
I know this is not so important for properly using synchronized, wait(), notify() and new locks, but I am interesting about what is really happening there :)
Thank you.

Answer 1

boba5555 wrote:
You wrote :"As far as I know, lock and monitor are used interchangeably in that context."
But, I am just not sure is that right or 'own monitor' and 'own lock' must be considered differently and actually, lock is not same as monitor. Question is about synchronized part in JDK 1.4 or later.Like I said, I've never seen a distinction between them as far as Java's language level multithreading concepts are concerned. Maybe the terms have different and distinct meanings in other contexts. Sometimes in Java we might say that a particular object is the monitor, and we own that object's (monitor's) lock, but even that's fairly loose usage. And any object can serve as a "monitor" in that sense, regardless of whether its methods are all synchronized or if its fields are all private or not.
I wouldn't worry about it too much. Unless you're writing your own VM or compiler, or implementing java.util.concurrent, you probably won't find a meaningful distinction.