Re: sync on local variable
Roedy Green wrote:
it is a bit fat for a SSCCE.
Well, the point of an SSCCE is that you trim down the "fat" code to a
minimal case that illustrates the problem. Part of the value in doing
that is that you often find the problem in the course of doing the
trimming.
Eric Sosman
Are you sure you didn't misread IntelliJ's complaint? The
thing that strikes me as odd about this code is that there are
three method calls made on row's object, only two of which are
synchronized on that object. It's conceivable that this is all
right, but it sure looks strange to me -- and perhaps IntelliJ
thinks it peculiar, too.
Roedy Green wrote:
I corrected the code to read:
AppToWatch row;
synchronized ( ALL_ROWS )
{
row = ALL_ROWS.get( rowIndex );
synchronized ( row )
{
state = row.getState();
}
}
...
It's not clear to me how this next section gets its 'row' reference.
Presumably it has to synchronize on 'ALL_ROWS' via the above
fragment. Regardless, any time you have inconsistent locking
protocols, e.g., using two locks in one place and only one in another,
you risk having strange problems, so it makes sense that IntelliJ
warns you about it. As with "unchecked" warnings, that doesn't mean
that you're wrong, necessarily, only that you're in dangerous
territory.
synchronized ( row )
{
url = row.getVersionURL();
marker = row.getMarker();
}
Now I get TWO message about synchorizing on row.
It's very difficult to reason about locks and synchronization when
they depend on changeable references, and involve different locking
sequences. I swan the warning is appropriate and you should either
live with it or come up with a locking protocol that's easier to
understand.
--
Lew