Question on Threads

[Ravi]

Hi,

Just wanted to clarify. Please correct me if I went wrong anywhere.

Threads seize their current execution in two ways
1) When they encounter a synchronized block and the object lock is not
available. They would be put in a Object Lock Monitor Queue. This
queue is managed by JVM. That is object lock acquiring and releasing
is automatically taken care by JVM on behalf of the thread
(programmer).
2) When the thread calls wait() from a synchronized block. It is then
put in Object's wait queue for which it acquired the lock and the lock
is released. Notify() by another thread brings it backs to life and
the fight for Object lock begins when it becomes the current execution
thread. The wait() and notify() have to programmed explicitly.

Thanks,
Ravi.

 

[Owen Jacobson]

Hi,

Just wanted to clarify. Please correct me if I went wrong anywhere.

Threads seize their current execution in two ways

I think you meant "cease", as in to stop or desist, not "seize", to
take by force...

1) When they encounter a synchronized block and the object lock is not
available. They would be put in a Object Lock Monitor Queue. This
queue is managed by JVM. That is object lock acquiring and releasing
is automatically taken care by JVM on behalf of the thread
(programmer).
2) When the thread calls wait() from a synchronized block. It is then
put in Object's wait queue for which it acquired the lock and the lock
is released. Notify() by another thread brings it backs to life and
the fight for Object lock begins when it becomes the current execution
thread. The wait() and notify() have to programmed explicitly.

Threads are also likely to be suspended any time they call a blocking
system service: even reading from a file, on most OSes, makes a thread
eligible for suspension so that the OS can schedule the disk read while
allowing other threads to use the CPU while the IO-bound thread waits
for its data.

There are also explicit locks that may or may not be implemented using
synchronization and wait()/notify() in the java.util.concurrent
package. On some platforms, there are native equivalents of the same
locking tools that are much faster than a pure-Java implementation
would be. Attempting to acquire a lock that isn't available will also
block the calling thread.

 

[Matt Humphrey]

I think you meant "cease", as in to stop or desist, not "seize", to take
by force...


Threads are also likely to be suspended any time they call a blocking
system service: even reading from a file, on most OSes, makes a thread
eligible for suspension so that the OS can schedule the disk read while
allowing other threads to use the CPU while the IO-bound thread waits for
its data.

There are also explicit locks that may or may not be implemented using
synchronization and wait()/notify() in the java.util.concurrent package.
On some platforms, there are native equivalents of the same locking tools
that are much faster than a pure-Java implementation would be. Attempting
to acquire a lock that isn't available will also block the calling thread.

Don't forget that the OS / scheduler may suspend a thread at any time
whatsoever (e.g. arbitrary end of the timeslice). Sometimes you just have
assume that the interleaved execution of multiple threads will proceed in
the the most inconvenient and malicious way possible.

Matt Humphrey http://www.iviz.com/

 

[Daniel Pitts]

Don't forget that the OS / scheduler may suspend a thread at any time
whatsoever (e.g. arbitrary end of the timeslice). Sometimes you just have
assume that the interleaved execution of multiple threads will proceed in
the the most inconvenient and malicious way possible.

It is even more complicated than that.

You must assume that all actions that aren't otherwise synchronized
might appear in some unexpected order to another thread.

For example:
if you have
public int a,b,c;

and Thread 1 code is:
a = 10;
b = 3*a;
c = a*b;

Thread 2 might see at any time a=0, b=0, c=0. Or a=10, b=0, c=300. Even
if thread 2 waits for c != 0, changes to a and b might not be visible to
it, so you would see a=0, b=0, c=300.

Understanding concurrency isn't as difficult as some people make it
sound, but there are quite a few subtleties to learn. My usual
suggestion is to read the book Java Concurrency In Practice:
<http://virtualinfinity.net/wordpress/technical-book-recommendations/java-concurrency-in-practice/>
This book if full of a complete and intuitive explanation of all of the
current Java Concurrency features, including Java 1.5 concurrency framework.

Hope this helps,
Daniel.

 

[Ravi]

Yep. At least I figured out that I should read Java Concurrency in
practice.
Thanks a lot Owen, Matt, Daniel.


Regards,
Ravi.