sync on local variable
in [Java Help]
|
From: Patricia Shanahan on 24 Mar 2010 19:21 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 24 Mar 2010 19:27 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 24 Mar 2010 19:36 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 24 Mar 2010 20:32 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 24 Mar 2010 20:42
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) |