Hmmm, yep you are right..
Heres a question, does the lock apply only to that object, or to objects
referenced within that object also? If it also extends to referenced
objects then perhaps there is a scenegraph object being referenced from this
thread and from within a Java3d thread also?
----- Original Message -----
From: Artur Biesiadowski <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 19, 2001 6:59 PM
Subject: Re: [JAVA3D] synchronizing within a behavior
David wrote:
>
> Vectors are synchronized data structures. By grabbing the synchronization
> lock on v then using getElements() you are effectively deadlocking
yourself.
Deadlock is not so easy thing. You need two locks, one kept by thread A
and second kept by thread B and then they need to try to acquire locks
held by other ones.
It is obvious that first synchronizing and the calling getElements from
same thread will not deadlock. Same thread hold the lock, so it will
just recurse synchronization one level deeper. Such thing might happen
with single-bit lock, but not with full monitor as it is implemented in
java.
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".
