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 22 Jul 2010 03:18 On Wed, 21 Jul 2010 20:39:59 -0700, markspace wrote: > 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. It isn't if the list escapes in a form where it can be modified. It is if the getNames method wraps its return value using Collections.unmodifiableList, but that has two effects different from doing it in the constructor: 1. The wrapping is done every time the getNames method is called instead of just once. 2. The list can be modified through the instance variable. Someone modifying the class could change it from technically-immutable to mutable, perhaps even without intending to. Making the list unmodifiable through the ivar makes any such change throw an exception that will lead to that programmer quickly realizing "oops". And then deciding if they really want to lose the class's immutability, or solve whatever they're trying to solve in some other way instead. But if they make it mutable it will be a conscious decision to do so and they will know to check the class's users to fix any code that assumes instances are immutable and that now won't work.
From: Alan Gutierrez on 22 Jul 2010 03:42 ClassCastException wrote: > 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. Thank you for considering the intent of the OP in your response. It is my intent that this worker thread not throw any exceptions and that all exceptions are considered catastrophic. The worker thread is writing a write ahead log, so any error is met by shutting down the thread to preserve the log, notifying waiting threads that it has shutdown. Waiting threads are waiting within the write ahead log library, which will detect the shutdown and throw an exception that says that the write ahead log has gone away. Future calls to the write ahead log throw exceptions. The absence of the log is unrecoverable. The obvious way for a write ahead log to fail is for the disk to fill. Thus, one of the messages you can send to the worker is to switch log directories, so that long before the disk fills, you can tell the log to write to a new disk. Why run the train to the end of the line, then put it back on the tracks after you laid some more? Is that anyway to run a railroad? Thus, I have a universal strategy for faults, which is, if things are not going as you expect, *stop* *writing* to the write ahead log, close it, shutdown completely, and start the forensics to figure out what went wrong. The rest of the system will come crashing down, but full disks, and the like, will do that. Which is why, sending it an interrupt is something that I would want to know immediately, so that I'd be in a better position to determine which bit of code is interrupting threads arbitrarily and excise it. This discussion helped me see that continue after interrupt is absolutely not what I want. So, whether or not I reset the interrupted status on the way down the drain is probably not that important, but I have no problem with adding that one line of code. -- Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy
From: Alan Gutierrez on 22 Jul 2010 03:54 markspace wrote: > 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. Just finished a longer response to CCE's message, where I explained my strategy for faults in the thread, but the same sentiment, thanks for considering the context of the OP (me) in the discussion. Thanks for pointing out the exception to the rule as it applies to my question. I laid out my fault-tolerance plans, because discussions about catch blocks can sometimes follow the "can't see the forest for the trees" reasoning. If its not clear (its late here) I'm agreeing with you and CCE that the bit about the interrupted state is good to know, but that the problem is wider than that, and the chances that anyone is going to do anything with the interrupted state flag are slim. -- Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy
From: Daniel Pitts on 22 Jul 2010 14:05 On 7/21/2010 5:50 PM, 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 ..." Actually, thats on page 93. Page 143 does state: "Only code that implements a thread's interruption policy may swallow an interruption request." So there are three possible responses: 1. Propagate the exception 2. Restore the interruption status. 3. Swallow the interrupt, but *only* if your code is part of the thread lifecycle management. > > 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. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Lew on 22 Jul 2010 21:26
Lew wrote: >> 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 ..." Daniel Pitts wrote: > Actually, thats on page 93. That's funny, actually I quoted it from the passage in the book that actually I had open to p. 142 as I actually typed. Actually. -- Lew |