Because Thread.yield() does not prevent busy waiting. Using a wait(N) there
can be no deadlock as this will timeout in N milliseconds. I am actually just
going to do a Thread.sleep(1) as this results in no cpu utilization and 1 ms
is a small performance penatly for the contending caller.
To see the problem with using Thread.yield(), try this simple program:
tmp 1046>cat tstYield.java
class tstYield implements Runnable
{
static long start;
static void yield()
{
Thread.yield();
}
static void sleep()
{
try
{
Thread.sleep(1);
}
catch(InterruptedException e)
{
}
}
public void run()
{
System.out.println("Start "+this);
long elapsed = System.currentTimeMillis() - start;
while( elapsed < 10000 )
{
yield();
elapsed = System.currentTimeMillis() - start;
}
System.out.println("End "+this);
}
public static void main(String[] args)
{
start = System.currentTimeMillis();
for(int t = 0; t < 2; t ++)
new Thread(new tstYield(), "T"+t).start();
}
}
When the threads attempt to pause using yield() rather than sleep(), there is
100% cpu utilization of the 10 sec period this program runs. When the use
sleep() there is no cpu utilization of the 10 sec period.
----- Original Message -----
From: "Bill Burke" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 4:25 PM
Subject: RE: [JBoss-dev] new wait(1000) not good
> Why not just a Thread.yield after mutex.release? With sleeping, don't you
> run the risk of starving out threads if the same EntityBean keeps on being
> accessed continually?
>
> I'm also worried about this same scenario with the new locking stuff in the
> mainline. With notifyAll instead of just notify is there a chance to starve
> threads? With notify aren't you guarateed FIFO for lock contention, but you
> wouldn't be guaranteed with a notifyAll?
>
> Bill
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
> > M Stark
> > Sent: Tuesday, July 17, 2001 6:22 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] new wait(1000) not good
> >
> >
> > Ok, I missed that mutex acquire at the start. I care less about
> > slowing down the
> > performance in the case of contending access than I do about burning
> > 100% cpu waiting for contention to resolve. Even a 10ms wait should remove
> > the spinning cpu so I'll stress test the issue by back porting
> > the latest lock
> > test from jbosstest to find a happy medium between performance throughput
> > and wasted cpu. I'll also just sleep the current thread after the
> > release of the
> > mutex.
> >
> > ----- Original Message -----
> > From: "Bill Burke" <[EMAIL PROTECTED]>
> > To: "Jboss-Development@Lists. Sourceforge. Net"
> > <[EMAIL PROTECTED]>
> > Sent: Monday, July 16, 2001 10:02 PM
> > Subject: [JBoss-dev] new wait(1000) not good
> >
> >
> > > Scott,
> > >
> > > Your 2.2 wait(1000)change will seriously slow down applications
> > that contend
> > > for the same Entity. In fact, it may even deadlock if requests for that
> > > Entity keep on coming in.
> > >
> > > The do..while loop does a mutex.acquire at the beginning. It
> > will not do a
> > > mutex.release until after the 1 second is up. If the transaction that
> > > currently holds the Entity invokes on the Entity more than one
> > time, it will
> > > be waiting for any thread currently hold the mutex to finish.
> > >
> > > Also, the mutex is acquired again in the finally clause of
> > > EntityInstanceInterceptor to synchronize on ctx.unlock and such.
> > >
> > > Bill
> > >
> >
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
