Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Threads not running in starting order (?)

Reply
Thread Tools

Threads not running in starting order (?)

 
 
Timo Nentwig
Guest
Posts: n/a
 
      12-13-2005
Hi!

Below I do start Thread t1 before t2. t1 tries to call print1() on a
Printer object and t1 print2() but only the first will success since it
obtains a lock on the Printer object. I'm surprised that although t1 is
started first the code prints "2". If I put a sleep(5) between the
starting of the threads t1 wins the race.

Can somebody explain?

public class SyncThreadTest
{
public static void main( String[] args )
{
new SyncThreadTest().go();
}

private void go()
{
Thread t1 = new Thread( new Runner( 1 ) );
Thread t2 = new Thread( new Runner( 2 ) );
System.out.println(t1.toString());
t1.start();

System.out.println(t2.toString());
t2.start();
}

class Runner implements Runnable
{
int i = 0;

public Runner( int i )
{
this.i = i;
}

public void run()
{
// Printer p = Printer.getInstance();
Printer p = new Printer();
// synchronized( p )
// synchronized( Printer.class )
synchronized( p.MUTEX )
{
while( true )
{
System.out.println(toString());
if( i == 1 ) p.print1();
else p.print2();

try
{
Thread.sleep( 500 );
}
catch( InterruptedException e )
{
}
}
}
}
}
}

class Printer
{
private static final Printer instance = new Printer();

public static final Object MUTEX = new Object();

public static Printer getInstance()
{
return instance;
}

public synchronized void print1()
{
System.out.println( 1 );
}

public synchronized void print2()
{
System.out.println( 2 );
}
}

 
Reply With Quote
 
 
 
 
Viator
Guest
Posts: n/a
 
      12-13-2005
There is no such guarantee in JAVA that threads will run in the order
they are started.
In fact on thread is totally independent of the other.

Amit

 
Reply With Quote
 
 
 
 
Timo Nentwig
Guest
Posts: n/a
 
      12-13-2005
Hmm. Well, but I can reproduce the scenario, it's *always* t2 that
obtains the lock.

 
Reply With Quote
 
Ingo R. Homann
Guest
Posts: n/a
 
      12-13-2005
Hi,

Timo Nentwig wrote:
> Hmm. Well, but I can reproduce the scenario, it's *always* t2 that
> obtains the lock.


In fact it isn't even guaranteed that the "undefined" behaviour is *not*
reproducable! (Beware of the two "not"s in this sentence!

"undefined" just means that it may look different on different OSs or JVMs.

(This is similar to random numbers: They *are* reproducable! There is
just no statistical pattern in them. Or ... no such pattern someone has
recognized by now...

Ciao,
Ingo

 
Reply With Quote
 
Monique Y. Mudama
Guest
Posts: n/a
 
      12-13-2005
On 2005-12-13, Timo Nentwig penned:
> Hmm. Well, but I can reproduce the scenario, it's *always* t2 that
> obtains the lock.
>


"Always" is a dangerous word, because it's impossible to prove.

That being said, it may be the case that the particular implementation
of the JVM you're using does always choose t2 for whatever reason, but
that another implementation (especially one running on top of a
different OS) would choose a different thread.

--
monique

Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
 
Reply With Quote
 
Timo Nentwig
Guest
Posts: n/a
 
      12-13-2005
Something else:

class Foo extends Thread
{
private Text text;
public Foo()
{
// this appears to be executed by caller thread
text = new Text(shell, ...); // -> Exception
}

public void run()
{
// this appears to executed by this thread
text = new Text(shell, ...); // -> alright
}
}

new Foo().start();

At least this is what I'm currently experience with SWT... see
http://dev.eclipse.org/viewcvs/index...=1.56#uithread

 
Reply With Quote
 
Thomas Hawtin
Guest
Posts: n/a
 
      12-13-2005
Monique Y. Mudama wrote:
> On 2005-12-13, Timo Nentwig penned:
>
>>Hmm. Well, but I can reproduce the scenario, it's *always* t2 that
>>obtains the lock.

>
> "Always" is a dangerous word, because it's impossible to prove.


Indeed.

> That being said, it may be the case that the particular implementation
> of the JVM you're using does always choose t2 for whatever reason, but
> that another implementation (especially one running on top of a
> different OS) would choose a different thread.


On my weirdo JVM/OS combination it's about 50/50 which comes first.
However, if I put the test in a loop (appending sleep/stop/join), it is
almost always the first thread that wins the race. That might give the
original poster an idea as to a possible cause. It might also indicate
that you should not rely on this sort of behaviour, even if it "works
for me".

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
 
Reply With Quote
 
zero
Guest
Posts: n/a
 
      12-13-2005
"Monique Y. Mudama" <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> On 2005-12-13, Timo Nentwig penned:
>> Hmm. Well, but I can reproduce the scenario, it's *always* t2 that
>> obtains the lock.
>>

>
> "Always" is a dangerous word, because it's impossible to prove.
>
> That being said, it may be the case that the particular implementation
> of the JVM you're using does always choose t2 for whatever reason, but
> that another implementation (especially one running on top of a
> different OS) would choose a different thread.
>


In other words, never ever make code that depends on threads running in a
particular order. If you need (part of) a thread to run before (part of) a
different one, use concurrency control.

--
Beware the False Authority Syndrome
 
Reply With Quote
 
jonb
Guest
Posts: n/a
 
      12-13-2005
I am trying to interrupt a thread. I have a long running thread and I
get a thead dump and find the name. Then I need this thread to be
interrupted. How do I pass the name of the thread into the java applet?


Here's my efforts so far:

public static final void InterruptThread( IData pipeline ) throws
ServiceException
{
boolean threadDone = false;
Thread toBeInterrupted = null;
String threadName = null;

IDataCursor idcPipeline = pipeline.getCursor();

idcPipeline.first("ThreadName");
threadName = (String)idcPipeline.getValue();
try {

// Pass name to Thread layer.
// toBeInterrupted = Thread[threadName];
toBeInterrupted.setName(threadName);
toBeInterrupted.join();
toBeInterrupted.currentThread().interrupt();
threadDone = true;
String errorCd = "Success";
idcPipeline.insertAfter("Success", errorCd);
}
catch(Exception e)
{
idcPipeline.insertAfter("Success", e);
//throw new ServiceException(e.getMessage());
}
finally
{
idcPipeline.destroy();
toBeInterrupted = null;
}
return;
}

I know that the Thread.setName just sets the name of the new thread to
the name that was input. This is probably not the thread I got a dump
on. How to I set the name of the thread in my service to the input name
that is type String?


zero wrote:
> "Monique Y. Mudama" <(E-Mail Removed)> wrote in
> news:(E-Mail Removed):
>
> > On 2005-12-13, Timo Nentwig penned:
> >> Hmm. Well, but I can reproduce the scenario, it's *always* t2 that
> >> obtains the lock.
> >>

> >
> > "Always" is a dangerous word, because it's impossible to prove.
> >
> > That being said, it may be the case that the particular implementation
> > of the JVM you're using does always choose t2 for whatever reason, but
> > that another implementation (especially one running on top of a
> > different OS) would choose a different thread.
> >

>
> In other words, never ever make code that depends on threads running in a
> particular order. If you need (part of) a thread to run before (part of) a
> different one, use concurrency control.
>
> --
> Beware the False Authority Syndrome


 
Reply With Quote
 
jonb
Guest
Posts: n/a
 
      12-13-2005
I am trying to interrupt a thread. I have a long running thread and I
get a thead dump and find the name. Then I need this thread to be
interrupted. How do I pass the name of the thread into the java applet?


Here's my efforts so far:

public static final void InterruptThread( IData pipeline ) throws
ServiceException
{
boolean threadDone = false;
Thread toBeInterrupted = null;
String threadName = null;

IDataCursor idcPipeline = pipeline.getCursor();

idcPipeline.first("ThreadName");
threadName = (String)idcPipeline.getValue();
try {

// Pass name to Thread layer.
// toBeInterrupted = Thread[threadName];
toBeInterrupted.setName(threadName);
toBeInterrupted.join();
toBeInterrupted.currentThread().interrupt();
threadDone = true;
String errorCd = "Success";
idcPipeline.insertAfter("Success", errorCd);
}
catch(Exception e)
{
idcPipeline.insertAfter("Success", e);
//throw new ServiceException(e.getMessage());
}
finally
{
idcPipeline.destroy();
toBeInterrupted = null;
}
return;
}

I know that the Thread.setName just sets the name of the new thread to
the name that was input. This is probably not the thread I got a dump
on. How to I set the name of the thread in my service to the input name
that is type String?


zero wrote:
> "Monique Y. Mudama" <(E-Mail Removed)> wrote in
> news:(E-Mail Removed):
>
> > On 2005-12-13, Timo Nentwig penned:
> >> Hmm. Well, but I can reproduce the scenario, it's *always* t2 that
> >> obtains the lock.
> >>

> >
> > "Always" is a dangerous word, because it's impossible to prove.
> >
> > That being said, it may be the case that the particular implementation
> > of the JVM you're using does always choose t2 for whatever reason, but
> > that another implementation (especially one running on top of a
> > different OS) would choose a different thread.
> >

>
> In other words, never ever make code that depends on threads running in a
> particular order. If you need (part of) a thread to run before (part of) a
> different one, use concurrency control.
>
> --
> Beware the False Authority Syndrome


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
3 ESSENTIAL TOOLS FOR STARTING AND MAINTAINING...3 ESSENTIAL TOOLSFOR STARTING AND MAINTAINING...3 ESSENTIAL TOOLS FOR STARTING ANDMAINTAINING... Oanh Bui C++ 0 04-27-2009 12:51 PM
3 ESSENTIAL TOOLS FOR STARTING AND MAINTAINING...3 ESSENTIAL TOOLSFOR STARTING AND MAINTAINING...3 ESSENTIAL TOOLS FOR STARTING ANDMAINTAINING... Oanh Bui C Programming 0 04-27-2009 12:51 PM
3 ESSENTIAL TOOLS FOR STARTING AND MAINTAINING...3 ESSENTIAL TOOLSFOR STARTING AND MAINTAINING...3 ESSENTIAL TOOLS FOR STARTING ANDMAINTAINING... Oanh Bui Python 0 04-27-2009 12:46 PM
Java Threads - Get running threads Pedro Pinto Java 2 04-08-2008 11:44 PM
some threads are not starting Junkone Ruby 2 01-03-2008 10:25 PM



Advertisments