Re: Question on Threads

Matt Humphrey wrote:
"Owen Jacobson" <angrybaldguy@xxxxxxxxx> wrote in message news:2007112300061275249-angrybaldguy@xxxxxxxxxxx
On 2007-11-22 23:15:42 -0800, Ravi <v.r.sankar@xxxxxxxxx> said:

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.

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.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
.

Relevant Pages

  • Re: This works, but I dont know why :)
    ... there are overlays still on disk the exe needs ... My Clipper exes, all overlaid, are always open ... Have an active lock? ... operation the first step in execution. ...
    (comp.lang.clipper)
  • Re: Question on Locks
    ... the execution plan will be a plain table scan. ... In a production database, columns that are searched on a regular basis ... And if a rare search ... size table than by some milliseconds of waiting for a lock to be released. ...
    (microsoft.public.sqlserver.programming)
  • Re: import in threads: crashes & strange exceptions on dual core machines
    ... Do you really mean the import statement can return without having executed the cookielib module code fully? ... Yet this costs the smoothness of app startup and corrupts my believe in Python capabs of "lazy execution on demand". ... I'd like to get a more fundamental understanding of the real problems than just a general "stay away and lock and lock everything without real understanding". ... The Import Lock should be a very hard lock: As soon as any thread imports something, all other threads are guaranteed to be out of any imports. ...
    (comp.lang.python)
  • Re: multiple threads grabbing items from a vector
    ... > However if Thread 1 finished before the others it would grab the next ... I don't think a lock is the problem. ... you really need the threads to synchronize their ... execution, ...
    (comp.lang.java.help)
  • Re: Multi Threading Options
    ... If the avatars struct could be modified by any other thread, ... your modifications are so short that releasing the main lock and locking just ... Given that the refresh is timer=based, you could probably eliminate all synchronization ... If it is a UI thread, then while the drawing is happening, the PostMessage ...
    (microsoft.public.vc.mfc)