Prev: web service behind firewall without DNS
Next: java plugin for linux firefox 3.6
From: Tom Anderson on 25 Mar 2010 23:01
On Wed, 24 Mar 2010, 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?

It's like the warning on the lack of a serialVersionUID in a Serializable
class. It isn't necessarily wrong, but there is a popular class of errors
that involve doing this.

tom

--
life finds a way
From: Daniel Pitts on 26 Mar 2010 16:18
On 3/25/2010 2:27 PM, Roedy Green wrote:
> On Wed, 24 Mar 2010 15:11:15 -0700, Roedy Green
> <see_website(a)mindprod.com.invalid> wrote, quoted or indirectly quoted
> someone who said :
>
>> 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?
>
> I got this response from an IntelliJ employee (probably a Russian with
> ESL).
>
> The point was synchronization only makes sense if two different
> threads syncing on the same instance and question arises how safe was
> an exchange, that two threads have same reference on their stacks.
> Most obviously "clean" subject to synchronize on is a final field.
> Synchronizing on a local reference might well be not a problem but
> generally not that easy to verify for correctness and easy thing to
> broke later.
One thing you can do is more the synchronization into the "Row" class,
and turn your operations into atomic operations, rather than have
external clients need to concern themselves with synchronization.

That way, the Row class can always sync on the same object (probably
"this", but not necessarily), and the client needn't care about it.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Eric Sosman on 26 Mar 2010 18:19
On 3/26/2010 4:18 PM, Daniel Pitts wrote:
> [...]
> One thing you can do is more the synchronization into the "Row" class,
> and turn your operations into atomic operations, rather than have
> external clients need to concern themselves with synchronization.
>
> That way, the Row class can always sync on the same object (probably
> "this", but not necessarily), and the client needn't care about it.

Are you sure he can do that? He calls three methods on
the row instance, in two synchronized blocks. Split them into
three blocks, and the pair that were together may no longer see
their row in the same state, because something may happen after
one method releases the lock and before the next acquires it.

--
Eric Sosman
esosman(a)ieee-dot-org.invalid
From: Daniel Pitts on 29 Mar 2010 15:52
On 3/26/2010 3:19 PM, Eric Sosman wrote:
> On 3/26/2010 4:18 PM, Daniel Pitts wrote:
>> [...]
>> One thing you can do is more the synchronization into the "Row" class,
>> and turn your operations into atomic operations, rather than have
>> external clients need to concern themselves with synchronization.
>>
>> That way, the Row class can always sync on the same object (probably
>> "this", but not necessarily), and the client needn't care about it.
>
> Are you sure he can do that? He calls three methods on
> the row instance, in two synchronized blocks. Split them into
> three blocks, and the pair that were together may no longer see
> their row in the same state, because something may happen after
> one method releases the lock and before the next acquires it.

The first call is synchronized separately. The second and third call
are in one synchronized block. The "atomicity" of those two calls can
be handled in one method:

class MarkedUrl {
private final VersionURL url;
private final Marker marker;

// appropriate contstructor and getters.
}

public class AppToWatch {
public syncronized MarkedUrl getMarkedUrl() {
return new MarkedUrl(versionUrl, marker);
}
}


--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: web service behind firewall without DNS
Next: java plugin for linux firefox 3.6