(e-mail address removed) coughed up:
To an extent, yes. Marking a method as synchronized will ensure that
no two threads enter the method at the same time (C1). By
synchronizing on the object, you create another possible relationship
that could be good or bad depending on the desired behavior, if you
have other methods that you do not want to access during the update,
such as a getter, you can synchronize it by using the same object for
the synchronization. But I would prefer to synchronize on the actual
value that is the purpose for the synchronization. It is both simpler
to read, and limits the possibility of unnecessary, and possibly
dangerous sync relationships.
class C2 {
private Integer value;
You need an actual instance here
value = new Integer(0);
...
public int getValue() {
synchronize(value) {
return value.intValue();
}
}
}
This is not a good idea in general as it goofs up compound operations later.
For example, the following:
C2 c = new C2();
c.setValue(c.getValue() + 1);
is not going to work and is going to need external synchronization one way
or the other. Using your technique, their is no way to get access to the
lock. It is far better to have the instance itself hold the lock, to allow
this:
synchronized(c)
{
c.setValue(c.getValue() + 1);
}
If you did it your way, but made the embedded Integer "value" object
exposed:
public class C2
{
// (.....code...)
public Object getLock() {return value;}
}
Then you could use it this way:
synchronized(c.getLock())
{
c.setValue(c.getValue() + 1);
}
But this is fraught with peril, because it is *not* what is expected by most
engineers.
This is to the side of whether or not you should use the
<scope> synchronized <type> <method name> {<body>}
or
<scope> <type> <method name> { synchronized(this) {<body>} }
I strongly suggest the latter unless you *absolutely* know that no
additional code will ever be added to the method that does not need
synchronization, and that you won't need the speed differential.
