Mutable Objects and Thread Boundaries
in [Java Help]
|
Prev: Const correctness (was Re: Oppinion on 'least priviledge', 'const correctness', etc.)
Next: Simple Hack To Get $2500 To Your PayPal Account.
From: ClassCastException on 21 Jul 2010 22:29 On Wed, 21 Jul 2010 01:22:11 -0700, markspace wrote: > Peter Duniho wrote: >> markspace wrote: >>> Joshua Cranmer wrote: >>> >>>> Immutability is the easiest way to guarantee safe publication: final >>>> fields guarantee that they can be used by any thread safely. >>> >>> Note quite. Final fields by themselves don't guarantee immutability >>> or safe publication. An immutable object must: >>> >>> * All fields are final. >>> * It is properly constructed. (No "this escapes." That bit is >>> important.) >>> * Its state cannot be modified after construction. >>> >>> Those three things must hold for an object to be treated as immutable >>> by the JVM. Mess up any one, and poof, no more immutability. >> >> I would be interested in seeing an example where your third point is >> violated but the first point is not. > > > class Mutable { > > private final List<String> names; > > public Mutable() { > names = new List<String>(); > names.add("Joe"); > names.add("Jim"); > } > > public List<String> getNames() { > return names; > } > } > > This class would be immutable except for the fact that the private final > variable "names" escapes and could be modified. That, and the fact that it won't compile. :-) Try this version for immutable goodness: public class Immutable { private final List<String> names; public Mutable() { List<String> n = new LinkedList<String>(); n.add("Joe"); n.add("Jim"); names = Collections.unmodifiableList(n); } public List<String> getNames() { return names; } }
From: ClassCastException on 21 Jul 2010 22:35 On Wed, 21 Jul 2010 20:50:06 -0400, Lew wrote: > Daniel Pitts wrote: >> I think you've misinterpreted something. There are possible spurious >> wake-ups, but there are *not* spurious interrupts. Object.wait(...) may > > You're absolutely right - my mistake. > >> *return* before the conditions are met, but will not through >> InterruptedException unless there is a true interrupt. > > The fact remains that 'InterruptedException' is not about SIGINT or > other OS signals but about response to an 'interrupted' condition. > > JCIP claims that there are two possible correct responses to receiving > an 'InterruptedException' - re-interrupt the thread itself (p. 142): "- > Propagate the exception... > "- Restore the interruption status ..." > > and the example on p. 144 is specifically about 'BlockingQueue#take()'. > He most emphatically does not recommend any of the approaches > recommended so far in this discussion. JCIP does not consider these to be acceptable? "- Exit the thread by returning from its run() method" "- Exit the thread by throwing another, unhandled exception, perhaps with the InterruptedException as its cause" That seems odd, since the first one is necessary if a thread is to actually interrupt while not producing any stack trace barf on the console (for cases when the interruption is NOT a bug) and the second is necessary if you want good layer decoupling and requiring every intermediate caller to handle or explicitly pass InterruptedException is poor layer decoupling. Then the standard method of "transforming" or wrapping layer-specific exceptions at layer borders seems indicated. In particular, in the case that the InterruptedException should not happen in production, you want to log it and either recover or abort, either the interrupted thread or the whole process/servlet/whatever.
From: markspace on 21 Jul 2010 23:24 Lew wrote: > He most emphatically does not recommend any of the approaches > recommended so far in this discussion. > JCIP, p 143: "If you don't want to or cannot propagate InterruptedExecptions (perhaps because your task is defined by a Runnable), you need to find another way to do preserve the interruption request. The standard way to do this is to restore the Interrupted status by calling interrupt() again. What you should _not_ do is swallow the InterruptedException by catching it and doing nothing in the catch block, *unless your code is actually implementing the interruption policy for a thread.*" *Emphasis* mine. So it's ok to swallow an InterruptedException, if you're implementing the thread's response to said interruption request. Which is what the OP is doing. He's deciding between ignoring, exiting, or logging and exiting. Whatever he decides, that will be his thread's interruption policy. Also, on page 141 he shows an example of swallowing the exception, with the very next act of the task being to exit the run() method of its Thread. Again basically the same thing as what we're advising the OP to do.
From: markspace on 21 Jul 2010 23:39 ClassCastException wrote: > names = Collections.unmodifiableList(n); Yeah, I messed-up with "new List()", but this line above isn't needed to make this object immutable. It's immutable without it.
From: Alan Gutierrez on 22 Jul 2010 02:04
Lew wrote: > Daniel Pitts wrote: >> I think you've misinterpreted something. There are possible spurious >> wake-ups, but there are *not* spurious interrupts. Object.wait(...) may > > You're absolutely right - my mistake. > >> *return* before the conditions are met, but will not through >> InterruptedException unless there is a true interrupt. > > The fact remains that 'InterruptedException' is not about SIGINT or > other OS signals but about response to an 'interrupted' condition. > > JCIP claims that there are two possible correct responses to receiving > an 'InterruptedException' - re-interrupt the thread itself (p. 142): > "- Propagate the exception... > "- Restore the interruption status ..." > > and the example on p. 144 is specifically about 'BlockingQueue#take()'. > He most emphatically does not recommend any of the approaches > recommended so far in this discussion. Like so: http://www.ibm.com/developerworks/java/library/j-jtp05236.html Then I believe OP really wants to make the worker a non-cancelable task, if that is a valid option according to Goetz. -- Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy |