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
