Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / November 2007

Tip: Looking for answers? Try searching our database.

Question on Threads

Thread view: 
Ravi - 23 Nov 2007 07:15 GMT
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 - 23 Nov 2007 08:06 GMT
> 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
[quoted text clipped - 6 lines]
> 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 - 23 Nov 2007 15:54 GMT
>> Hi,
>>
[quoted text clipped - 27 lines]
> 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 - 23 Nov 2007 18:04 GMT
>>> Hi,
>>>
[quoted text clipped - 30 lines]
> 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-concurr
ency-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.
Signature

Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Ravi - 26 Nov 2007 05:51 GMT
Yep. At least I figured out that I should read Java Concurrency in
practice.  :)
Thanks a lot Owen, Matt, Daniel.

Regards,
Ravi.
On Nov 23, 11:04 pm, Daniel Pitts
<newsgroup.spamfil...@virtualinfinity.net> wrote:

> >>> Hi,
>
[quoted text clipped - 60 lines]
> --
> Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.