Path: csiph.com!usenet.pasdenom.info!news.albasani.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.pionier.net.pl!news.dialog.net.pl!not-for-mail From: Arivald Newsgroups: comp.lang.java.programmer Subject: Re: What is so bad aboud Thread.stop() ? Date: Wed, 14 Aug 2013 01:08:16 +0200 Organization: Dialog Net Lines: 38 Message-ID: References: <8fe57dc2-a323-4821-941c-4036663cbce5@googlegroups.com> <7cb96188-91ce-4c2b-ace8-5eeb1b30815e@googlegroups.com> <5f47910f-5450-4578-818c-cac2d4b6f436@googlegroups.com> <39a5e684-7cf8-4f00-ba3b-7e280b19d669@googlegroups.com> NNTP-Posting-Host: dynamic-62-87-147-50.ssp.dialog.net.pl Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.dialog.net.pl 1376435468 2336 62.87.147.50 (13 Aug 2013 23:11:08 GMT) X-Complaints-To: abuse@dialog.net.pl NNTP-Posting-Date: Tue, 13 Aug 2013 23:11:08 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Thunderbird/23.0 In-Reply-To: <39a5e684-7cf8-4f00-ba3b-7e280b19d669@googlegroups.com> Xref: csiph.com comp.lang.java.programmer:24959 W dniu 2013-08-14 00:22, Lew pisze: > taq...@gmail.com wrote: >> I am trying to see what is new that Thread.stop brings to that consideration >> versus other mundane and accepted Thread interactions. > > Seems to me that > http://docs.oracle.com/javase/6/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html > explains it rather well. > > I found it fast via > http://lmgtfy.com/?q=Java+dangers+of+Thread.stop > > You've cited part of this, presumably from the Javadocs: > "This method is inherently unsafe. Stopping a thread with Thread.stop causes it to unlock all of the > monitors that it has locked (as a natural consequence of the unchecked ThreadDeath exception > propagating up the stack). If any of the objects previously protected by these monitors were in an > inconsistent state, the damaged objects become visible to other threads, potentially resulting in > arbitrary behavior." > > I'm not sure what else you need to know here. This is both normative and complete. > So, if You can write thread in a way when it never create "inconsistent objects" that are accessible from other threads, calling Thread.stop() will be safe. And how to make sure such condition? For example, by using specialized queues for input and output data from thread. Queues written in a way that guarantee that it never is inconsistent. Yes, it is possible, using java.util.concurrent.atomic it is possible to write lock-free and thread safe queues. http://www.ibm.com/developerworks/library/j-jtp04186/ -- Arivald