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 / January 2007

Tip: Looking for answers? Try searching our database.

Understanding thread behavior

Thread view: 
bobroberts_333@yahoo.com - 24 Jan 2007 20:06 GMT
I've taken a "deadlock" sample from a java Sun tutorial page and
modified it slightly. It's exhibiting some behavior that I find
unexpected.

Here is the sample code. Keep in mind that it's supposed to deadlock.

public class Deadlock {
   static class Friend {
       private final String name;
       public Friend(String name) {
           this.name = name;
       }
       public String getName() {
           return this.name;
       }
       public synchronized void step1(Friend thefriend) {
           System.out.println(this.name + "    : locked by: " +
this.name);
           System.out.println(this.name + "    : trying to get lock
on: " + thefriend.getName());
           thefriend.step2(this);
           System.out.println(this.name + "    : released lock on: " +
thefriend.getName());
       }
       public synchronized void step2(Friend thefriend) {
           System.out.println(this.name + "    : locked by " +
thefriend.getName());
       }
   }

   public static void main(String[] args) {

       System.out.println("There are two separate locks involved
here.");
       System.out.println("One lock is for the 'Bob' object, and one
for the 'Roberts' object");
       System.out.println("");

       final Friend bob = new Friend("Bob");
       final Friend roberts = new Friend("Roberts");

       new Thread(new Runnable() {
           public void run() { bob.step1(roberts); }
       }).start();

       new Thread(new Runnable() {
           public void run() { roberts.step1(bob); }
       }).start();
   }
}

Note the three System calls in main. If the System calls are present,
the code will execute and NO deadlock will occur (95% of the time...).
If I take out the System calls, the deadlock occurs as expected nearly
100% of the time.

I don't know much about JVMs and Java in general. This was a learning
exercise. Can someone give me a
reasonable explanation of why adding the System calls before any
objects are even created, might cause timing
issues that would throw off the deadlock?

I'm a bit at a loss here...

Any input is appreciated. Thanks!

-Bob
bobroberts_333@yahoo.com - 24 Jan 2007 20:33 GMT
I think I've got my own answer here. I think the System calls are
causing timing differences later in the program because
of context switching in the OS. The process is probably getting
switched out and changing the time slice remaining for
the process enough that subsequent switches occur at different
locations during code execution. If I remember correctly,
the time slice on Solaris (on which I'm running this) is 100ms.

If anyone else has any ideas, please feel free to add them...

Thanks.

On Jan 24, 3:06 pm, bobroberts_...@yahoo.com wrote:
> I've taken a "deadlock" sample from a java Sun tutorial page and
> modified it slightly. It's exhibiting some behavior that I find
[quoted text clipped - 62 lines]
>
> -Bob
Tom Hawtin - 25 Jan 2007 00:07 GMT
> I think I've got my own answer here. I think the System calls are
> causing timing differences later in the program because
[quoted text clipped - 3 lines]
> locations during code execution. If I remember correctly,
> the time slice on Solaris (on which I'm running this) is 100ms.

It's quite possibly the loading of code in java.io (and potentially
other compiling) taking time. If you do it at the start of main, it has
all happened before you start your threads. If you don't your first
thread grabs a lock, and then spends time dawdling, in which time the
other thread can grab the other lock first.

The strange effects with having compilers threads and on stack
replacement. You should also note that multicore (or multiprocessor)
machines may behave (i.e. deadlock) differently. Software developed on a
multicore machine may start deadlocking on single core machine, and vice
versa.

So, "it looks alright to me" and "it works on my PC" are not good enough
excuses...

Tom Hawtin


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.