meaning of synchronized keyword

[tri]

Hi,

I have some questions on the meaning of the synchronized keyword.

Scenario 1:

Let's say a thread, ThreadA, calls a synchronized method but the
synchronized method already is locked by another thread, ThreadB.

ThreadA is now blocked and must wait. Does Java put ThreadA to sleep?
Or does ThreadA spin on the cpu?

Also, let's say ThreadC calls the synchronized method. When ThreadB
is done with the lock, does ThreadA have priority? Or is the lock
"randomly" given to either ThreadC or ThreadA?

The above example does not use wait() and notify().


Thank You,

Tri

 

[Maik Heller]

Hi,

I have some questions on the meaning of the synchronized keyword.

Scenario 1:

Let's say a thread, ThreadA, calls a synchronized method but the
synchronized method already is locked by another thread, ThreadB.

ThreadA is now blocked and must wait. Does Java put ThreadA to sleep?
Or does ThreadA spin on the cpu?

Also, let's say ThreadC calls the synchronized method. When ThreadB
is done with the lock, does ThreadA have priority? Or is the lock
"randomly" given to either ThreadC or ThreadA?

The above example does not use wait() and notify().


Thank You,

Tri

as far as i know, windows doesnt work fifo on locking but mac does. if
you have to rely on the order which thread comes next, you have to
programm a pipe.

 

[kevin]

Hi,

I have some questions on the meaning of the synchronized keyword.

Scenario 1:

Let's say a thread, ThreadA, calls a synchronized method but the
synchronized method already is locked by another thread, ThreadB.

ThreadA is now blocked and must wait. Does Java put ThreadA to sleep?
Or does ThreadA spin on the cpu?

Also, let's say ThreadC calls the synchronized method. When ThreadB
is done with the lock, does ThreadA have priority? Or is the lock
"randomly" given to either ThreadC or ThreadA?

The above example does not use wait() and notify().


Thank You,

Tri

this is the page in sun's site that specifies what 'synchronized' is
supposed to mean

http://java.sun.com/docs/books/jls/second_edition/html/jIX.fm.html

As i remember the books... any thread that is unable to gain a lock on
a monitor (a code frag with 'synchronized' round it), it's put in a
blocked state and will effectively stop executing. Only one process or
thread can execute, and it must be in the state runnable, clearly a
blocked thread is not so it waits till it gets its status changed.
when a thread is done with the code in the monitor, it releases the
lock of the monitor. There is no way to determine which thread will
pick it up next except perhaps by thread priority. higher priority
thread will get a look in first to the cpu, but as i understand it,
the next thread to grab it will be determined by the scheduler
algorithm.

 

[John C. Bollinger]

Hi,

I have some questions on the meaning of the synchronized keyword.

Scenario 1:

Let's say a thread, ThreadA, calls a synchronized method but the
synchronized method already is locked by another thread, ThreadB.

Methods are not locked -- objects are. This is a very important
distinction, because it means that if one thread is executing a method
synchronized on object A, then no other thread can enter _any_ method
(or block) synchronized on object A. Moreover, if a thread is executing
synchronized method M of object A, that places no restriction on other
threads executing method M of any other object.

ThreadA is now blocked and must wait. Does Java put ThreadA to sleep?
Or does ThreadA spin on the cpu?

Neither. Thread A is "blocked on monitor access". It does not get any
CPU time allocated to it until it can acquire the relevant object's
monitor, but that's different from sleeping.

Also, let's say ThreadC calls the synchronized method. When ThreadB
is done with the lock, does ThreadA have priority? Or is the lock
"randomly" given to either ThreadC or ThreadA?

Java does not specify how a thread is chosen to receive the monitor from
among those threads blocked on it, so it is an implementation question.
Likely different implementations do it differently.


John Bollinger
(e-mail address removed)

 

[tri]

Methods are not locked -- objects are. This is a very important
distinction, because it means that if one thread is executing a method
synchronized on object A, then no other thread can enter _any_ method
(or block) synchronized on object A. Moreover, if a thread is executing
synchronized method M of object A, that places no restriction on other
threads executing method M of any other object.


Neither. Thread A is "blocked on monitor access". It does not get any
CPU time allocated to it until it can acquire the relevant object's
monitor, but that's different from sleeping.

What happens to a blocked thread? It gets context switched out and
another thread gets scheduled on that cpu?

If so, it gets signaled when the lock has been released? and then has
the opportunity to acquire the lock and execute the method?

 

[Ann]

"John C. Bollinger" <[email protected]> wrote in message

What happens to a blocked thread? It gets context switched out and
another thread gets scheduled on that cpu?

If so, it gets signaled when the lock has been released? and then has
the opportunity to acquire the lock and execute the method?

Who sends the signal?

 

[Eric Sosman]

[ThreadA tries to synchronize on an already-locked object]

ThreadA is now blocked and must wait. Does Java put ThreadA to sleep?
Or does ThreadA spin on the cpu?

Neither. Thread A is "blocked on monitor access". It does not get any
CPU time allocated to it until it can acquire the relevant object's
monitor, but that's different from sleeping.

What happens to a blocked thread? It gets context switched out and
another thread gets scheduled on that cpu?

If so, it gets signaled when the lock has been released? and then has
the opportunity to acquire the lock and execute the method?

John has given you the programmer's view, the high-
level description of what happens when a thread tries to
acquire an already-locked lock: the thread stalls (that
is, it ceases to make progress) until it is able to acquire
the lock. The low-level mechanisms that put the thread to
sleep and that awaken it again are different on different
JVM implementations, because the still lower-level mechanisms
on which the JVM relies are different on different O/Ses and
hardware.

On some implementations the thread will go to sleep as
soon as it finds the lock already taken. On others the
thread may spin for a little while and then go to sleep.
On still others the thread may not go to sleep at all, but
just spin (making no progress) until the lock is released.
The JVM implementors choose a method that works well (or is
intended to work well) for the platform at hand. Different
platforms have different trade-offs, so different JVMs use
different strategies.

All you know (and all you need to know, unless you are
trying to implement a JVM yourself) is that the thread will
make no progress until acquires the lock, and that the lock
can be acquired by only one thread at a time. The details
of how the thread's progress is stopped and how it eventually
resumes are of little interest to the Java programmer. In
particular, if you find yourself writing a program that depends
on the scheduling quirks of one JVM, you are almost certainly
writing a non-portable program.

 

[Ann]

[ThreadA tries to synchronize on an already-locked object]
ThreadA is now blocked and must wait. Does Java put ThreadA to sleep?
Or does ThreadA spin on the cpu?

Neither. Thread A is "blocked on monitor access". It does not get any
CPU time allocated to it until it can acquire the relevant object's
monitor, but that's different from sleeping.

What happens to a blocked thread? It gets context switched out and
another thread gets scheduled on that cpu?

If so, it gets signaled when the lock has been released? and then has
the opportunity to acquire the lock and execute the method?

John has given you the programmer's view, the high-
level description of what happens when a thread tries to
acquire an already-locked lock: the thread stalls (that
is, it ceases to make progress) until it is able to acquire
the lock. The low-level mechanisms that put the thread to
sleep and that awaken it again are different on different
JVM implementations, because the still lower-level mechanisms
on which the JVM relies are different on different O/Ses and
hardware.

On some implementations the thread will go to sleep as
soon as it finds the lock already taken. On others the
thread may spin for a little while and then go to sleep.
On still others the thread may not go to sleep at all, but
just spin (making no progress) until the lock is released.
The JVM implementors choose a method that works well (or is
intended to work well) for the platform at hand. Different
platforms have different trade-offs, so different JVMs use
different strategies.

All you know (and all you need to know, unless you are
trying to implement a JVM yourself) is that the thread will
make no progress until acquires the lock, and that the lock
can be acquired by only one thread at a time. The details
of how the thread's progress is stopped and how it eventually
resumes are of little interest to the Java programmer.

Does this mean that notify() is not needed in this case? Then
when should notify() be used?

 

[Babu Kalakrishnan]

Does this mean that notify() is not needed in this case? Then
when should notify() be used?

notify() doesn't come in the picture for threads that are blocked due to
this reason (i.e lock being held by some other thread).

The notify() method is always used alongside a wait(). When you call
notify on an Object this causes a signal to be sent to any one thread
that had called "wait()" on that particular object and is blocked in the
wait state. The signal is *not* sent to other threads that were simply
blocked trying to enter a synchronization block on the object.

BK

 

[tri]

John has given you the programmer's view, the high-

level description of what happens when a thread tries to
acquire an already-locked lock: the thread stalls (that
is, it ceases to make progress) until it is able to acquire
the lock. The low-level mechanisms that put the thread to
sleep and that awaken it again are different on different
JVM implementations, because the still lower-level mechanisms
on which the JVM relies are different on different O/Ses and
hardware.

On some implementations the thread will go to sleep as
soon as it finds the lock already taken. On others the
thread may spin for a little while and then go to sleep.
On still others the thread may not go to sleep at all, but
just spin (making no progress) until the lock is released.
The JVM implementors choose a method that works well (or is
intended to work well) for the platform at hand. Different
platforms have different trade-offs, so different JVMs use
different strategies.

All you know (and all you need to know, unless you are
trying to implement a JVM yourself) is that the thread will
make no progress until acquires the lock, and that the lock
can be acquired by only one thread at a time. The details
of how the thread's progress is stopped and how it eventually
resumes are of little interest to the Java programmer. In
particular, if you find yourself writing a program that depends
on the scheduling quirks of one JVM, you are almost certainly
writing a non-portable program.

The multithreaded application I'm writing runs on Windows 2000 on a
quad processor machine (Intel Xeon 500Mhz processors). I'm comparing
Java's synchronized locking with lock-free algorithms. Looking at the
test results, I do need to know what happens to a thread when it is
blocked using synchronized locking. I'm also using JDK1.5.

Does it spin? Does it go to sleep? Does the operating system put it
on a blocked list?

Where can I find such information for the specific platform I'm
writing my application on? I need to know these things to explain the
results of my tests.

Thank You,

Tri

 

[Ann]

The multithreaded application I'm writing runs on Windows 2000 on a
quad processor machine (Intel Xeon 500Mhz processors). I'm comparing
Java's synchronized locking with lock-free algorithms. Looking at the
test results, I do need to know what happens to a thread when it is
blocked using synchronized locking. I'm also using JDK1.5.

Does it spin?
no

Does it go to sleep? Does the operating system put it
on a blocked list?

Where can I find such information for the specific platform I'm
writing my application on? I need to know these things to explain the
results of my tests.

Thank You,

Tri

 

[John C. Bollinger]

The multithreaded application I'm writing runs on Windows 2000 on a
quad processor machine (Intel Xeon 500Mhz processors). I'm comparing
Java's synchronized locking with lock-free algorithms. Looking at the
test results, I do need to know what happens to a thread when it is
blocked using synchronized locking. I'm also using JDK1.5.

Does it spin? Does it go to sleep? Does the operating system put it
on a blocked list?

The [JVM] thread scheduler will not schedule it for execution while it
is blocked on monitor access. It will not consume CPU cycles itself,
but the VM might consume more resources when there are many live threads
than when there are few. How any of that looks from the OS side depends
on the VM implementation.

Where can I find such information for the specific platform I'm
writing my application on? I need to know these things to explain the
results of my tests.

You can consult the release notes for your JVM. You can consider
reading the JVM spec (a free download from Sun), but I'm pretty sure
that it leaves the particular details you want to the discretion of VM
implementors. You could consider trying to contact Sun's JVM
development team with specific questions; I'm not sure whether that's
likely to get a response. Java in general tends to try to hide
implementation and OS-specific details, so exposing such things is not a
frequent topic of conversation here.

If you post some of your test results then you may get some help on the
analysis directly; some of us might find that an interesting topic in
itself.


John Bollinger
(e-mail address removed)

 

[tri]

no

Where can I verify this? Is there some published work stating this?

Thank You,

Tri

 

[xarax]

"Ann" <[email protected]> wrote in message


Where can I verify this? Is there some published work stating this?

Read the JVM Spec and the JLS spec. When a thread is blocked
while waiting for a monitor (that's what happens when a
synchronized keyword is encountered), the thread will not
consume CPU time (because the JVM will not execute Java
code beyond the monitor-entry until the monitor is available).
Other threads may continue to execute. The blocked thread
will not poll the monitor, because that would use CPU time.
Instead, when the other thread that already has the monitor
releases the lock, the JVM will mark the blocked thread as
dispatchable. Later, when the JVM decides that the thread
can be dispatched, it try again to obtain the monitor. The
algorithm for dispatching is implementation-dependent, but
it guaranteed to avoid starvation.

If you need lock-free algorithms, remember that the Java
memory model is highly dependent on the memory flushing
that occurs during monitor-entry and monitor-exit (i.e.,
obtaining and freeing a lock via "synchronized" keyword).

J2SE 5.0 (aka JDK 1.5.0) has new classes for mutual exclusion
and atomic operations. The atomic operations are mapped
to platform-specific hardware facilities for high speed
interlocked updates, like a Compare&Swap facility. On
platforms that don't have modern hardware facilities,
the operation is mapped to a synchronized operation.

 

[Sudsy]

xarax wrote:

J2SE 5.0 (aka JDK 1.5.0) has new classes for mutual exclusion
and atomic operations. The atomic operations are mapped
to platform-specific hardware facilities for high speed
interlocked updates, like a Compare&Swap facility. On
platforms that don't have modern hardware facilities,
the operation is mapped to a synchronized operation.

Sorry, but this old-timer has to chuckle. The parallel drawn between "modern
hardware" and the "Compare&Swap facility" is amusing to me. I just pulled my
System/370 Reference Summary and it's dated July 1984. So this facility has
been available on IBM mainframes for at least two decades. I couldn't have
written that Communications Transport Control Program (CTCP) in GCS/VTAM
(multiple tasks in a single address space!) without it.
Eveything old is new again...
No offence intended. It's just interesting to me how often the disparaged
mainframe is still a source of good ideas. Maybe they were "doing it right"
after all?

 

[xarax]

xarax wrote:


Sorry, but this old-timer has to chuckle. The parallel drawn between "modern
hardware" and the "Compare&Swap facility" is amusing to me. I just pulled my
System/370 Reference Summary and it's dated July 1984. So this facility has
been available on IBM mainframes for at least two decades. I couldn't have
written that Communications Transport Control Program (CTCP) in GCS/VTAM
(multiple tasks in a single address space!) without it.
Eveything old is new again...
No offence intended. It's just interesting to me how often the disparaged
mainframe is still a source of good ideas. Maybe they were "doing it right"
after all?

Actually, the IBM mainframe memory model (even way back then)
is far superior to the Java memory model. There is actually
no need for Compare&Swap on the IBM mainframe due to its
advanced memory model. There are software mutex algorithms
that will work on the IBM mainframe memory model without
interlocked updates. Those same algorithms cannot work
on most modern microprocessor memory models without a
special hardware interlocked update. For the IBM mainframe,
Compare&Swap is a nice convenience but not absolutely
required.

 

[marcus]

(see *)
Tri, trying to reconstruct your thought process and actual questions /
issues / needs based on your posts is numbing my brain. You start by
asking questions incorrectly using jargon like "spin" and "sleep", you
display a reasonably shallow understanding of the topic as a whole, then
you insist you need documented specifications to prove some sort of
theory you are working on. Why in heaven's name are you posting to a
newsgroup asking if there is a published work specifying how a thread
functions in a JVM? Of course there is a spec. A JVM could not be
written without a spec.

Could you read the spec if you had it? I imagine if you could read the
spec you would know where to find it and what questions to ask. If not,
how are you going to prove anything -- take a newsgroup survey? Or you
just need a paragraph or to to plagiarize for your project.

gods help the next generation of programmers. Learn to paint.