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
