Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!feeder.erje.net!us.feeder.erje.net!news2.arglkargh.de!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 08:42:17 +0200 Organization: Dialog Net Lines: 42 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-78-8-155-68.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 1376462707 13647 78.8.155.68 (14 Aug 2013 06:45:07 GMT) X-Complaints-To: abuse@dialog.net.pl NNTP-Posting-Date: Wed, 14 Aug 2013 06:45:07 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Thunderbird/23.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:24967 W dniu 2013-08-14 01:45, markspace pisze: > On 8/13/2013 4:08 PM, Arivald wrote: > >> 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/ > > > That's a clever idea, but I'm not sure I'd want to rely on it working in > production code. How much trouble is it really to not call > Thread.stop()? That's what I see as the principle argument here. I'm > not really convinced of the need for Thread.stop(), so all these > workarounds seem moot. > > If one were really desperate, ok I can see having to resort to something > like this, but it seems like there has to be several bad engineering and > management decisions to get there. > > I agree that Thread.stop() should be not used in standard operations. But I still advise using lock-free queues, especially in high load and highly multi-threading applications. Such structures does not need to synchronize, so no thread will wait for other thread, resulting in boosted performance. Ans such highly multi-threading application can benefit from Thread.stop(). For example, lets assume application use MapReduce, and governing thread/computer detects that one of threads works too long (other threads/computers already finished same work). It may be error in code or hardware malfunction that cause infinite loop. In such case governing thread will use Thread.stop() to kill misbehaving thread. -- Arivald