From: Patricia Shanahan on
Arne Vajh�j wrote:
> On 24-03-2010 18:11, Roedy Green wrote:
>> The IntelliJ code Inspector (lint) slapped my wrist for synchronising
>> on a local variable. What's the problem with that? The sync is on
>> the object, not the reference, right?
>
> Local variables are thread specific.
>
> Passing on a local variable to another thread via some
> global variable/singleton/cache would be a pretty bad design.
>
> I can understand the complaint.
>
> Arne
>
> PS: yes - it is the object not the ref.

It may be a case of import, rather than export. Suppose the method for
obtaining a reference to some object is fairly expensive, and
synchronized. Each thread could have obtained a reference to the same
object and cached it in a local variable.

It's difficult to know if the message was valid or not without an SSCCE.

Patricia
From: Arne Vajhøj on
On 24-03-2010 19:21, Patricia Shanahan wrote:
> Arne Vajh�j wrote:
>> On 24-03-2010 18:11, Roedy Green wrote:
>>> The IntelliJ code Inspector (lint) slapped my wrist for synchronising
>>> on a local variable. What's the problem with that? The sync is on
>>> the object, not the reference, right?
>>
>> Local variables are thread specific.
>>
>> Passing on a local variable to another thread via some
>> global variable/singleton/cache would be a pretty bad design.
>>
>> I can understand the complaint.
>
> It may be a case of import, rather than export. Suppose the method for
> obtaining a reference to some object is fairly expensive, and
> synchronized. Each thread could have obtained a reference to the same
> object and cached it in a local variable.

It could be.

But I would tend to believe that would be messy as well. To be able to
easily verify that threads are indeed synchronizing on the same object,
then I think it is best if is relative simple to see what is being
synchronized on.

> It's difficult to know if the message was valid or not without an SSCCE.

I don't think the tool does super sophisticated code analysis. Most
likely it just have some simple rules and flag things that looks weird.
If they are good enough, then the developer can ignore the warning. And
a good tool would have the option to store the ignore decision.

Arne
From: Mike Schilling on
Roedy Green wrote:
> The IntelliJ code Inspector (lint) slapped my wrist for synchronising
> on a local variable. What's the problem with that? The sync is on
> the object, not the reference, right?

Right, it's not illegal and may be correct. But it may be incorrect as
well, and probably is will be unless you can guarantee that the local will
point to the same instance in all threads. IntelliJ thinks enough people
make that mistake that it's worth warning about. It's similar to

while (methodCall());
i++;

That's legal and might be exactly what you meant to do, but the first
semicolon is likely enough to be spurious that a lint-like tool should say
something.


From: Arved Sandstrom on
markspace wrote:
> Arved Sandstrom wrote:
>> Roedy Green wrote:
>>> The IntelliJ code Inspector (lint) slapped my wrist for synchronising
>>> on a local variable. What's the problem with that? The sync is on
>>> the object, not the reference, right?
>>
>> Each thread gets its own local variable. Defeats the purpose of
>> synchronizing on one.
>
>
> If you later export that local reference to another thread or object, it
> should be fine. It's valid to synchronize on a object that some other
> part of the system will see later.
>
> If you just synchronized on a local variable and then let it go out of
> scope, yeah, that's a pretty serious "D'oh!" moment.
>
I think all the responses have pretty much narrowed in on the same
things: the sync is indeed on the object, which means that however you
obtain/store a reference to that object that everything is using as a
lock, it's certainly legal to sync on an object referred to locally.

But since it's something that is somewhat unusual, and could (probably)
be a mistake, I imagine IntelliJ is flagging it along the lines of what
Mike suggested.

AHS
From: Roedy Green on
On Wed, 24 Mar 2010 15:55:30 -0700, markspace <nospam(a)nowhere.com>
wrote, quoted or indirectly quoted someone who said :

>If you later export that local reference to another thread or object, it
>should be fine. It's valid to synchronize on a object that some other
>part of the system will see later.

I have a JTable. I get a row put it in a local variable and
synchronise on that. Does that not lock anyone else getting that
row, even if they have nothing to do with my local variable?

AppToWatch row;
synchronized ( ALL_ROWS )
{
row = ALL_ROWS.get( rowIndex );
state = row.getState();
}
....
synchronized ( row )
{
url = row.getVersionURL();
marker = row.getMarker();
}
--
Roedy Green Canadian Mind Products
http://mindprod.com

Don�t worry about people stealing an idea; if it�s original, you�ll have to shove it down their throats.
~ Howard Aiken (born: 1900-03-08 died: 1973-03-14 at age: 73)