how to make this code thread safer?
in [Java Programming]
|
From: Arne Vajhøj on 19 Jul 2010 22:23 On 19-07-2010 13:08, Peter Duniho wrote: > Note the use of a dedicated object reference for synchronization. In > general, it is poor practice to use the "this" reference for > synchronization, though that's what declaring a method as "synchronized" > does. It's not the end of the world to use "this", but doing so "leaks" > some of your implementation, and introduces the possibility of some > other code not related to your own taking the same monitor, increasing > contention as well as the complexity of the locking scenarios. Someone wrote this many years ago for C#/.NET. Everybody in the C#/.NET world has repeated it since then. But no one seems to have ever seen a real world case where it was a problem. It is not best practice to avoid it. Best practices is about avoiding real problems. It just an urban legend type of thing. Arne
From: markspace on 19 Jul 2010 22:29 Joshua Cranmer wrote: > This is only true for final fields. Regular fields do not have the same > luxury--hence why it is often preferred to have immutable objects in Java. One small addendum: any fields (not just final) that are not initialized but left at their default (0 or null) state are also thread safe. The JLS guarantees that the default values for all objects are visible to all threads. Once you start assigning stuff though, all bets are off.
From: Peter Duniho on 19 Jul 2010 22:36 Arne Vajh�j wrote: > On 19-07-2010 14:51, Peter Duniho wrote: >> The first mechanism has to do with semantics surrounding object >> construction. In .NET, the specification ensures that whatever happens >> in the constructor "happens before" any other code that uses the >> reference after the constructor completes (.NET doesn't actually use the >> term "happens-before", but it's the same idea). I would expect Java to >> be the same in this respect. > > Where does it say that? > > The only thing I can find seems to say the exact opposite: > > <quote> > It is explicitly not a requirement that a conforming implementation of > the CLI guarantee that all state updates > performed within a constructor be uniformly visible before the > constructor completes. > </quote> Hmm. Well, the above quote is inapplicable, because it describes what is true _before_ the constructor completes, not _after_. My comment was with respect to _after_. That said, it is possible I am misremembering, and only "readonly" fields (similar to "final" fields in Java) are guaranteed to be visible. I was pretty sure the spec declared that for all fields, but I haven't actually looked through the spec recently myself. And you appear to have, so if you couldn't find it, maybe it's not there. But, if so, I wonder why they would bother to write the statement you quoted. After all, if there's no guarantee that state updates are visible after the constructor completes, why would anyone think they would be guaranteed to be visible before the constructor completes? And thus why would there be a need to state explicitly there's no such guarantee? Pete
From: Peter Duniho on 19 Jul 2010 22:37 Arne Vajh�j wrote: > On 19-07-2010 13:08, Peter Duniho wrote: >> Note the use of a dedicated object reference for synchronization. In >> general, it is poor practice to use the "this" reference for >> synchronization, though that's what declaring a method as "synchronized" >> does. It's not the end of the world to use "this", but doing so "leaks" >> some of your implementation, and introduces the possibility of some >> other code not related to your own taking the same monitor, increasing >> contention as well as the complexity of the locking scenarios. > > Someone wrote this many years ago for C#/.NET. > > Everybody in the C#/.NET world has repeated it since then. > > But no one seems to have ever seen a real world case where > it was a problem. > > It is not best practice to avoid it. > > Best practices is about avoiding real problems. > > It just an urban legend type of thing. Yes, you've said all that before (in the C# newsgroup). You're still wrong. If you like, we can just copy/paste the back-and-forth we had there to this newsgroup. Pete
From: Chintan(Neo) on 20 Jul 2010 04:01
Hi www, I read your code. i would like to ask some questions regarding the code? have you tried the code and is it giving NullPointerException or it is ur assumption? b'se as the class or method or objects are not 'static', every instance of the class will have its own variables and so it should be thread safe. 'this.checkSomething();' will make tim/ tom null but only of that object/thread and not of other objects/ threads. I dont find any problem in the code. I am not very experienced at multi threaded programming but this is my primary and logical thinking says. Please check and let me know. Regards, Chintan |