Yes,
What you say about deadlock makes sense, but none of MY code in
OrderedBehavior.run creates new threads (Who knows what Java3D is doing). I
don't understand how deadlock can have been created. Anyway, I'm now using
toArray() and the problem seems to be gone. Since Vector is a synchronized
class can I assume that its elements can't be changed by any other thread
until the whole toArray() method has completed? If that is the case, then I
guess I won't need synchronization at all?
Thanks,
Raffi
-----Original Message-----
From: Artur Biesiadowski [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 19, 2001 4:33 PM
To: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] synchronizing within a behavior
"Kasparian, Raffi J." wrote:
>
> I have gotten no response after submitting this message twice to this
> message group and once to the Java3D beta program. Surely someone out
there
> can at least tell me if it looks like I'm using synchronization properly
in
> theory?
[...]
> synchronized( v ){// v is a Vector and a variable member of this class.
> for( Enumeration e2 = v.elements(); e2.hasMoreElements(); ){
> OrderableBehavior r = (OrderableBehavior)e2.nextElement();
> r.run();
> }
> v.clear();
> }
Don't know what happens exactly, but most probably something in run
method is causing something else to try to get same lock from other
thread. Or something like this. Anyway, try to call run methods from
outside the lock. Something like
Vector oldVec;
synchronized (v)
{
oldVec = v;
v = new Vector();
}
for( Enumeration e2 = oldVec.elements(); e2.hasMoreElements(); )
{
OrderableBehavior r = (OrderableBehavior)e2.nextElement();
r.run();
}
or create a clone or perform toArray inside synchronized.
It is generally a good idea to keep synchronized blocks as short as
possible (sometimes even at cost of extra alloc as in this case).
Anyway, it would be nice to determine extactly what is causing a
deadlock - just for fun. Try locking jvm and then press CTRL-Break or
CTRL-/ (depending on platform) - you will get full thread dump. You
should be able to determine which thread (together with call trace) is
waiting on monitor held by other thread.
Artur
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
