synchronized block in synchronized static method

D

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?
 
T

Thomas Fritsch

dmcreyno said:
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.
 
R

Robert Klemme

dmcreyno said:
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
 
C

Chris Uppal

dmcreyno said:
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
 
E

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?
 
C

Chris Uppal

Red said:
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
 
M

Mark Space

Chris said:
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.
 
C

Chris Smith

Mark Space said:
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.
 
M

Mark Space

Chris said:
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!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top