Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.CARNet.hr!gregory.BNet.hr!not-for-mail From: Josip Almasi Newsgroups: comp.lang.java.programmer Subject: Re: thread pool with CachedThreadPool Date: Thu, 17 Apr 2014 12:12:14 +0200 Organization: B.net Hrvatska d.o.o. Lines: 31 Message-ID: References: <12vmb157ulwwb.1cmusyz7wuuyi$.dlg@40tude.net> NNTP-Posting-Host: cpe-94-253-152-146.zg.cable.xnet.hr Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: gregory.bnet.hr 1397729534 337 94.253.152.146 (17 Apr 2014 10:12:14 GMT) X-Complaints-To: abuse@globalnet.hr NNTP-Posting-Date: Thu, 17 Apr 2014 10:12:14 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:28117 On 04/17/2014 07:11 AM, Kevin McMurtrie wrote: > In article , > Robert Klemme wrote: > >> On 16.04.2014 12:42, Josip Almasi wrote: >>> >>> Blocked thread itself spends no cpu time. >>> Running thread may spend some more cpu time though, for lock checks. >>> Real issue is flushing pipeline to ensure cache coherency among all cpu >>> cores. >>> So, more 'synchronized' statements your single running thread >>> encounters, more cpu stalls. It's not really 'taking' cpu time, it's >>> wasting it. >> >> I don't think this applies. We were talking about threads idling in the >> pool. [snip] Probably so. But, see, it's not just 'small ammount of kernel time', issues go all the way to cpu design. > Sun's thread pools are garbage [snip] Dang. Thanks Kevin, you possibly saved me a lot of time. Regards...