RE: [JBoss-dev] new wait(1000) not good
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of James > Cook > Sent: Monday, July 23, 2001 7:55 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] new wait(1000) not good > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > > fleury > > > Let's finish and stabilize the 2.* series. This will need to go > > in the new > > 3.* series where we can rethink locking and clustering. A > > locking that will > > support distribution and multiple instances will be interesting. > > If you mean synchronizing bean access in the container across multiple > instances of the container, I would ask why? If I misinterpreted, I > apologize. > Our app is a perfect example. We have one large database server and 3-4 smaller App servers each running Jetty/JBoss. We need to synchronize some entity beans across JBoss instances so we use "select...for update". I firmly believe though that the datastore should be doing all the synchronization in a clustered environment. > I currently know of *no* EJB container that can synch EJB instances across > distributed containers. Gemstone (brokat now) may be able to, but only > because they have a persistent cache architecture which is really a > distributed database, and it is external to their container anyways. The > other guys (and you guys) may be able to do it by throwing enough > resources > at it, but it would still be very difficult. > > In the end, I scratch my head and wonder why? I can't even think of a good > reason to synch access to beans in a *single* container. No one > really does Read about commit option A. I think synching access in the container for 'A' is a perfectly viable solution. Although, using something like "select...for update" would make the current JBoss code base much more simple. The question is, does something like "select...for update" exist for all DBs? probably not. > it anymore besides jBoss. It has been proven to be contrary to performance > and can be prone to deadlock issues. > I agree, but synching is perfectly viable for commit option A. Option B and C is another story. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new wait(1000) not good
Hi Maybe also wrong but I think the distributed locking/synchr. will be necessary when you run EJBs in a clustered environment where there is not one EJB Container but several of them able to serve and transparent to the client. On the other hand I know that IBM WebSphere uses an external DB for the same reason as well. Andy -Original Message- From: James Cook [mailto:[EMAIL PROTECTED]] Sent: Monday, July 23, 2001 4:55 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] new wait(1000) not good > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Let's finish and stabilize the 2.* series. This will need to go > in the new > 3.* series where we can rethink locking and clustering. A > locking that will > support distribution and multiple instances will be interesting. If you mean synchronizing bean access in the container across multiple instances of the container, I would ask why? If I misinterpreted, I apologize. I currently know of *no* EJB container that can synch EJB instances across distributed containers. Gemstone (brokat now) may be able to, but only because they have a persistent cache architecture which is really a distributed database, and it is external to their container anyways. The other guys (and you guys) may be able to do it by throwing enough resources at it, but it would still be very difficult. In the end, I scratch my head and wonder why? I can't even think of a good reason to synch access to beans in a *single* container. No one really does it anymore besides jBoss. It has been proven to be contrary to performance and can be prone to deadlock issues. I'll stop there until I figure out if I understood the proposed direction correctly. :-) jim ___ 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
RE: [JBoss-dev] new wait(1000) not good
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Let's finish and stabilize the 2.* series. This will need to go > in the new > 3.* series where we can rethink locking and clustering. A > locking that will > support distribution and multiple instances will be interesting. If you mean synchronizing bean access in the container across multiple instances of the container, I would ask why? If I misinterpreted, I apologize. I currently know of *no* EJB container that can synch EJB instances across distributed containers. Gemstone (brokat now) may be able to, but only because they have a persistent cache architecture which is really a distributed database, and it is external to their container anyways. The other guys (and you guys) may be able to do it by throwing enough resources at it, but it would still be very difficult. In the end, I scratch my head and wonder why? I can't even think of a good reason to synch access to beans in a *single* container. No one really does it anymore besides jBoss. It has been proven to be contrary to performance and can be prone to deadlock issues. I'll stop there until I figure out if I understood the proposed direction correctly. :-) jim ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new wait(1000) not good
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
|Burke
|Sent: Thursday, July 19, 2001 4:59 PM
|To: [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] new wait(1000) not good
|
|
|Yeah, sure, having multiple instances makes things easier, they
|can only be
|applied to commit option B and C. For option A, you're going to need to
|share instances and thus you'll need some locking mechanism. I
|totaly agree
|though, for B and C, let the datastore manage locks and serialization.
interesting.
Let's finish and stabilize the 2.* series. This will need to go in the new
3.* series where we can rethink locking and clustering. A locking that will
support distribution and multiple instances will be interesting.
we will also slow down on versioning. Major updates like this are better
served in a new full revision. I anticipate a 6mo cycle,
marcf
|
|Bill
|
|> -Original Message-
|> From: [EMAIL PROTECTED]
|> [mailto:[EMAIL PROTECTED]]On Behalf Of James
|> Cook
|> Sent: Thursday, July 19, 2001 4:30 PM
|> To: [EMAIL PROTECTED]
|> Subject: RE: [JBoss-dev] new wait(1000) not good
|>
|>
|> All of this entity contention is an optional thing we will have to
|> explicitly "turn on", correct?
|>
|> I prefer to have the container create multiple instances of identical
|> entities (same home, same pk) and handle the concurrency in the database.
|>
|> jim
|>
|> > -Original Message-
|> > From: [EMAIL PROTECTED]
|> > [mailto:[EMAIL PROTECTED]]On
|Behalf Of Scott
|> > M Stark
|> > Sent: Tuesday, July 17, 2001 10:45 PM
|> > To: [EMAIL PROTECTED]
|> > Subject: Re: [JBoss-dev] new wait(1000) not good
|> >
|> >
|> > 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 < 1 )
|> > {
|> > 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
|>
RE: [JBoss-dev] new wait(1000) not good
Yeah, sure, having multiple instances makes things easier, they can only be
applied to commit option B and C. For option A, you're going to need to
share instances and thus you'll need some locking mechanism. I totaly agree
though, for B and C, let the datastore manage locks and serialization.
Bill
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of James
> Cook
> Sent: Thursday, July 19, 2001 4:30 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] new wait(1000) not good
>
>
> All of this entity contention is an optional thing we will have to
> explicitly "turn on", correct?
>
> I prefer to have the container create multiple instances of identical
> entities (same home, same pk) and handle the concurrency in the database.
>
> jim
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
> > M Stark
> > Sent: Tuesday, July 17, 2001 10:45 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] new wait(1000) not good
> >
> >
> > 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 < 1 )
> > {
> > 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
RE: [JBoss-dev] new wait(1000) not good
All of this entity contention is an optional thing we will have to
explicitly "turn on", correct?
I prefer to have the container create multiple instances of identical
entities (same home, same pk) and handle the concurrency in the database.
jim
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
> M Stark
> Sent: Tuesday, July 17, 2001 10:45 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] new wait(1000) not good
>
>
> 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 < 1 )
> {
> 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 th
Re: [JBoss-dev] new wait(1000) not good
> "Georg" == Georg Rehfeld <[EMAIL PROTECTED]> writes: Georg> notifyAll seems to be MUCH better as of the docs: Georg> | The awakened threads will compete in the usual manner with | Georg> any other threads that might be actively competing to | Georg> synchronize on this object; for example, the awakened threads Georg> | enjoy no reliable privilege or disadvantage in being the Georg> next | thread to lock this object. Georg> So every thread, if it was waiting before or just coming in Georg> fresh, has the same chance to get the lock and proceed, Georg> avoiding starvation. this is not implied by the snippet you posted. all it says is that the threads in the wait set "will compete in the usual manner", which is no more fully specified than the case with notify(). no scheduling method is implied in either notify() or notifyAll(), so you can make no guarantees of fairness. also, notifyAll() can lead to the so-called 'thundreing herd' of threads waking, competing for the lock, and (all but one) going back to sleep again. that said, any quality JVM will implement some sort of quasi-fair scheduling policy, so it's not likely to lead to starvation. but if you really want fairness, you cannot rely on the builtins. there is a excellent discussion of this, and some examples on writing a FIFO scheduler, in Doug Lea's 'Concurrent Programming in Java, 2nd Ed', which I recommend highly. -- joe ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new wait(1000) not good
Bill and Georg, I wrote a lock manager several years ago, so my comments may be out dated. I remember that, if I wanted to wake the waiting threads in a specific order (LIFO FIFO), we would have each thread wait on a different object so it could be awoken individually. Before the thread waits on the object it puts the object in a collection. When the thread with the lock releases the lock, it selects the next thread from the collection, removes the object, and calls notify. It is a pretty simple trick in the code. By the way, has anyone considered using an external lock manager instead of coding one directly into the interceptor. When I wrote my lock manager there were no freely available managers, but I think there are several now. Dain > -Original Message- > From: Bill Burke [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 18, 2001 11:31 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] new wait(1000) not good > > > Thanks Georg for clearing that up. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On > Behalf Of Georg > > Rehfeld > > Sent: Thursday, July 19, 2001 12:06 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] new wait(1000) not good > > > > > > Hi Bill, > > > > > 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? > > > > notify does NOT guarantee FIFO awakening of threads: the docs > > explicitely state: > > > > | The choice is arbitrary and occurs at the discretion of the > > | implementation. > > > > i.e. a LIFO or whatever implementation might lead to starvation. > > > > notifyAll seems to be MUCH better as of the docs: > > > > | The awakened threads will compete in the usual manner with > > | any other threads that might be actively competing to > > | synchronize on this object; for example, the awakened threads > > | enjoy no reliable privilege or disadvantage in being the next > > | thread to lock this object. > > > > So every thread, if it was waiting before or just coming in > > fresh, has the same chance to get the lock and proceed, avoiding > > starvation. > > > > Bye > > Georg > > ___ ___ > > | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg > > |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 > > > > > > > > ___ > > 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
RE: [JBoss-dev] new wait(1000) not good
Thanks Georg for clearing that up. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Georg > Rehfeld > Sent: Thursday, July 19, 2001 12:06 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] new wait(1000) not good > > > Hi Bill, > > > 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? > > notify does NOT guarantee FIFO awakening of threads: the docs > explicitely state: > > | The choice is arbitrary and occurs at the discretion of the > | implementation. > > i.e. a LIFO or whatever implementation might lead to starvation. > > notifyAll seems to be MUCH better as of the docs: > > | The awakened threads will compete in the usual manner with > | any other threads that might be actively competing to > | synchronize on this object; for example, the awakened threads > | enjoy no reliable privilege or disadvantage in being the next > | thread to lock this object. > > So every thread, if it was waiting before or just coming in > fresh, has the same chance to get the lock and proceed, avoiding > starvation. > > Bye > Georg > ___ ___ > | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg > |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 > > > > ___ > 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
Re: [JBoss-dev] new wait(1000) not good
Hi Bill, > 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? notify does NOT guarantee FIFO awakening of threads: the docs explicitely state: | The choice is arbitrary and occurs at the discretion of the | implementation. i.e. a LIFO or whatever implementation might lead to starvation. notifyAll seems to be MUCH better as of the docs: | The awakened threads will compete in the usual manner with | any other threads that might be actively competing to | synchronize on this object; for example, the awakened threads | enjoy no reliable privilege or disadvantage in being the next | thread to lock this object. So every thread, if it was waiting before or just coming in fresh, has the same chance to get the lock and proceed, avoiding starvation. Bye Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] new wait(1000) not good
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 < 1 )
{
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
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
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-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
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
> M Stark
> Sent: Monday, July 16, 2001 11:27 PM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins
> EntityInstanceInterceptor.java
>
>
> User: starksm
> Date: 01/07/16 20:26:51
>
> Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_2
> EntityInstanceInterceptor.java
> Log:
> Add a simple wait(1000) to avoid the spin wait that currently
> exists in the
> presence of transcation contention.
>
> Revision ChangesPath
> No revision
>
>
> No revision
>
>
> 1.28.2.1 +273 -265
> jboss/src/main/org/jboss/ejb/plugins/EntityInstanceInterceptor.java
>
> Index: EntityInstanceInterceptor.java
> ===
> RCS file:
> /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/EntityInstance
> Interceptor.java,v
> retrieving revision 1.28
> retrieving revision 1.28.2.1
> diff -u -r1.28 -r1.28.2.1
> --- EntityInstanceInterceptor.java 2001/01/12 00:05:53 1.28
> +++ EntityInstanceInterceptor.java 2001/07/17 03:26:50 1.28.2.1
> @@ -1,9 +1,9 @@
>/*
> -* JBoss, the OpenSource EJB server
> -*
> -* Distributable under LGPL license.
> -* See terms of license at gnu.org.
> -*/
> + * JBoss, the OpenSource EJB server
> + *
> + * Distributable under LGPL license.
> + * See terms of license at gnu.org.
> + */
>package org.jboss.ejb.plugins;
>
>import java.lang.reflect.Method;
> @@ -39,272 +39,280 @@
>import org.jboss.util.Sync;
>
>/**
> -* This container acquires the given instance.
> -*
> -* @see
> -* @author Rickard Öberg ([EMAIL PROTECTED])
> -* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
> -* @author href="mailto:[EMAIL PROTECTED]";>Sebastien Alborini
> -* @version $Revision: 1.28 $
> -*/
> + * This container acquires the given instance.
> + *
> + * @see
> + * @author Rickard Öberg ([EMAIL PROTECTED])
> + * @author mailto:[EMAIL PROTECTED]";>Marc Fleury
> + * @author href="mailto:[EMAIL PROTECTED]";>Sebastien Alborini
> + * @version $Revision: 1.28.2.1 $
> + */
>public class EntityInstanceInterceptor
>extends AbstractInterceptor
>{
> -// Constants -
> -
> -// Attributes
> -protected EntityContainer container;
> -
> -// Static
> -
> -// Constructors --
> -
> -// Public
> -public void setContainer(Container container)
> -{
> -this.container = (EntityContainer)container;
> -}
> -
> -public Container getContainer()
> -{
> -return container;
> -}
> -
> -// Interceptor implementation
> --
> -public Object invokeHome(MethodInvocation mi)
> -throws Exception
> -{
> -// Get context
> -EnterpriseContext ctx =
> ((EntityContainer)getContainer()).getInstancePool().get();
> -mi.setEnterpriseContext(ctx);
> -
> -// It is a new context for sure so we can lock it
> -ctx.lock();
> -
> -try
> -{
> -// Invoke through interceptors
> -return getNext().invokeHome(mi);
> -} finally
> -{
> -// Always unlock, no matter what
> -ctx.unlock();
> -
> -// Still free? Not free if create() was called successfully
> -if (ctx.getId() == null)
> -{
> -container.getInstancePool().free(ctx);
> -}
> -}
> -}
> -
> -public Object invoke(MethodInvocation mi)
> -throws Exception
> -{
> -// The id store is a CacheKey in the case of Entity
> -CacheKey key = (CacheKey)mi.getId();
> -
> -// Get cache
> -AbstractInstanceCache cache =
> (AbstractInstanceCache)container.getInstanceCache();
> -Sync mutex = (Sync)cache.getLock
