Synchronizing on Local Lock Object? Buggy?

Thread view:

johnhurt@gmail.com - 06 Apr 2006 20:14 GMT

Is this code below Not properly synchronized?

Multiple threads could enter this part of a method... I found this. It
seems to me that the LOCK is local thus if a thread tried to lock on
it, it'd never be locked because each thread would have its own local
LOCK! Am I correct?

if(cacheSuccessful && tempMap != null && !tempMap.isEmpty())
{
final Object LOCK = new Object();
synchronized(LOCK)
{
myCacheMap = tempMap;
}
}

Reply to this Message

Thomas Hawtin - 06 Apr 2006 19:27 GMT

> Is this code below Not properly synchronized?
>
[quoted text clipped - 11 lines]
> }
> }

Yup, it's pointless. The naming convention kind of implies that LOCK
should be a static final, which would work (as long as the rest of the
code is sane). In versions of Java prior to 1.5, it does have some
highly obscure effect on the program. From 1.5, the lock can be
eliminated altogether by the JVM.

Tom Hawitn

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

Patricia Shanahan - 06 Apr 2006 20:26 GMT

> Is this code below Not properly synchronized?
>
[quoted text clipped - 11 lines]
> }
> }

Pointless, anyway. This will never have to wait to get the lock, because
each thread executing the code has a different object.

If it were something like:

final Object LOCK = SomeClass.getMyLockObject();

and SomeClass.getMyLockObject always returned the same object, it would
work.

I am also concerned about checks being done outside the synchronized
block, and not repeated inside it. Maybe tempMap is null, by the time
the assignment is executed.

Patricia

Reply to this Message

Synchronizing on Local Lock Object? Buggy?

Free Magazines