Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: blmblm@myrealbox.com Newsgroups: comp.lang.java.programmer Subject: Re: What is so bad aboud Thread.stop() ? Date: 13 Aug 2013 20:18:52 GMT Organization: None Lines: 86 Message-ID: References: <8fe57dc2-a323-4821-941c-4036663cbce5@googlegroups.com> <7cb96188-91ce-4c2b-ace8-5eeb1b30815e@googlegroups.com> X-Trace: individual.net dHg+uv0n1VQY/TfPNV7aMQrVi0WN6dU6rqP8pyOsg/fLSzrLlb X-Orig-Path: not-for-mail Cancel-Lock: sha1:ldjczbRrv4D00MCxKIwNx/1F6/4= X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Xref: csiph.com comp.lang.java.programmer:24955 In article <7cb96188-91ce-4c2b-ace8-5eeb1b30815e@googlegroups.com>, wrote: > On Sunday, August 11, 2013 1:46:49 PM UTC-4, blmblm @ myrealbox. com wrote: > > In article , > > > > wrote: > > > > ... > > > You can use objects that are readonly to the stoppable thread to send > > > information to that thread, and use objects that are read by the > > > monitor (or other threads) only after the thread has successfully > > > finished (or at least completed the tasks during which it may be > > > stopped) to get information back. The fact that I might have stopped > > > the thread in some circumstances doesn't mean I can't use objects > > > created by it when I do let it finish. > > > > > > That *sounds* plausible .... But it occurs to me that assigning values > > to variable is no longer a simple matter -- with smart compilers and > > caches and so forth, it's hard to be sure when the value will actually > > be visible to other threads, which is presumably why the Java memory > > model (with its "happens before" and so forth) exists. Can someone who > > knows that model comment on how it might apply here? > > > > > > B. L. Massingill > > > It's certainly true that the memory model is abstruse, but that's true of > interthread communications generally and not specific to killed threads. Agreed. (Do I seem to be saying otherwise?) Indeed, that's the point I was trying to make in saying "that's why the Java memory model exists" -- meaning that without a model, it would be difficult if not impossible to say anything meaningful about when one could rely on values being visible to other threads. > > If I have an object that is mutable by a thread that I might kill at some > point, it would be pretty nifty if the fact that the thread was going to be > killed in the future affected it before I killed it...a thiotimoline thread! Um, I don't get the connection between this and what I wrote. ? > And after the monitor kills a thread, it seems like discarding all > potentially mutated objects should be a pretty robust way to limit the > effects. > Um, yes .... So you're saying if thread A kills thread B, to be safe thread A should also discard any objects potentially mutated by thread B? > > But I'd agree that if there is a third thread involved, things get a lot more > complex -- though again that's true of thread communication generally. > Third thread? Now I'm really confused. But to get back to your presumably-safe scenario, in which thread B finishes normally. It seems reasonable to assume that all values assigned in thread B should then be visible to other threads. What I'm wondering, though, is whether that's explicitly required by the Java memory model. (Yeah, yeah, really I should probably just go read up on the memory model myself, but I thought someone else might know, and that this might be an interesting point to raise anyway.) > > Tom McGlynn > > > might be killed in the future could affect it before I kill it > -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor.