synchronized block in synchronized static method

[dmcreyno]

I recently stumbled across this idiom.

public static synchronized int getThreadCountMax()
{
synchronized (ARTClientThread.class)
{
return threadCountMax;
}
}

Its a synchronized static method with a synchronized block. Looks
redundant to me. Doesn't the synchronized static method use the class
object?

 

[Thomas Fritsch]

I recently stumbled across this idiom.

public static synchronized int getThreadCountMax()
{
synchronized (ARTClientThread.class)
{
return threadCountMax;
}
}

Its a synchronized static method with a synchronized block. Looks
redundant to me.

It is just as dumb as writing this:
public static int getThreadCountMax()
{
synchronized (ARTClientThread.class)
{
synchronized (ARTClientThread.class)
{
return threadCountMax;
}
}
}

Doesn't the synchronized static method use the class
object?

I does.

 

[Robert Klemme]

I recently stumbled across this idiom.

public static synchronized int getThreadCountMax()
{
synchronized (ARTClientThread.class)
{
return threadCountMax;
}
}

Its a synchronized static method with a synchronized block. Looks
redundant to me. Doesn't the synchronized static method use the class
object?

It does - but it's own class. If this code is not in class
ARTClientThread then it has different semantics than the version without
the block.

Kind regards

robert

 

[Chris Uppal]

public static synchronized int getThreadCountMax()
{
synchronized (ARTClientThread.class)
{
return threadCountMax;
}
}

Its a synchronized static method with a synchronized block. Looks
redundant to me. Doesn't the synchronized static method use the class
object?

If getThreadCountMax() is a method at the outer level of ARTClientThread then
it is redundant.

If it's a member of any other class (including classes nested inside
ARTClientThread) then it's not redundant. In that case, depending on the
design of the locking strategy, it could be any of: wasteful, absolutely
necessary, or an invitation to create deadlocks.

-- chris

 

[Eric Sosman]

dmcreyno wrote On 06/26/06 12:59,:

I recently stumbled across this idiom.

public static synchronized int getThreadCountMax()
{
synchronized (ARTClientThread.class)
{
return threadCountMax;
}
}

Its a synchronized static method with a synchronized block. Looks
redundant to me. Doesn't the synchronized static method use the class
object?

If the method is part of the ARTClientThread class, the
same Class object is locked redundantly.

If the method is part of some other class, that class'
Class object and ARTClientThread.class are distinct and both
are locked once each. This isn't "redundant," but it seems
"useless."

Has this code been victimiz-- er, "improved" by one of
those semi-automatic refactoring tools? The gadgets that
take the thought out of coding and produce thoughtless code?

 

[dmcreyno]

As others have asked, it is a method on ARTClientThread. So, redundant
it is.

 

[Chris Uppal]

Therefore,
synchronized block will not be required with the example.

[This is in addition to what Chris Smith has already explained]

Consider this:

privant int value;

public int getValue() { return value; }

public void aMethod()
{
while (true)
doSomethingWith(getValue());
}

Since getValue() is not synchronised, and uses no sychronisation blocks, the
compiler (which really means JITer) is perfectly within its right to first
inline the method call, as if the original Java source was:

public void aMethod()
{
while (true)
doSomethingWith(value);
}

and then to "notice" that value does not change during the loop, and to
optimise the field access into a local variable access:

public void aMethod()
{
int __xyz123 = value;
while (true)
doSomethingWith(__xyz123);
}

So, in another thread /does/ change value, the loop will never "see" the new
value.

Synchronisation acts not only to control the (potentially very loose) coupling
between the state of RAM seen by different CPUs, but also to inform the
optimiser of the limits to what it is allowed to assume.

-- chris

 

[Mark Space]

Locks are recursive in Java; hence, no deadlock.

I don't see how recursion would help, but I'll take your word on the no
deadlock bit.

Do you mean "able to be used in recursive algorithms" maybe? I think
that might be re-entrant or something.

 

[Chris Smith]

I don't see how recursion would help, but I'll take your word on the no
deadlock bit.

Do you mean "able to be used in recursive algorithms" maybe? I think
that might be re-entrant or something.

A recursive lock is a lock that keeps track of who is holding it, and a
lock count. When the holder tries to grab the lock a second time, it
simply increments that counter. When the holder releases the lock,
then, it decrements that counter. Only when the counter reaches zero is
the lock actually released.

This does solve this specific deadlock problem. Of course, it's still
possible to write deadlocks in Java, but it does require two locks.

 

[Mark Space]

A recursive lock is a lock that keeps track of who is holding it, and a
lock count. When the holder tries to grab the lock a second time, it
simply increments that counter. When the holder releases the lock,
then, it decrements that counter. Only when the counter reaches zero is
the lock actually released.

Ok, first time I've heard that term, applied to mutex or semaphores
anyway. Thanks!