From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6f24e26ea2e03c4 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!postnews.google.com!h18g2000yqo.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Threadpool with priority version 1.1 ... Date: Wed, 24 Mar 2010 14:46:45 -0700 (PDT) Organization: http://groups.google.com Message-ID: <7794a413-34e9-4340-abcc-a6568246fc38@h18g2000yqo.googlegroups.com> References: <21e6697e-fd7c-4c5e-93dc-8d894449b5e6@f8g2000yqn.googlegroups.com> <4ba9e189$0$6886$9b4e6d93@newsspool2.arcor-online.net> <1id5xnuz0x892$.1odbic5ppiv07.dlg@40tude.net> <4baa27f2$0$6770$9b4e6d93@newsspool3.arcor-online.net> NNTP-Posting-Host: 85.1.157.152 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1269467206 30357 127.0.0.1 (24 Mar 2010 21:46:46 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 24 Mar 2010 21:46:46 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: h18g2000yqo.googlegroups.com; posting-host=85.1.157.152; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:9752 Date: 2010-03-24T14:46:45-07:00 List-Id: On 24 Mar, 17:40, Warren wrote: > Another barrier I see to this is the high cost of > starting a new thread and stack space allocation. > Somehow you gotta make thread startup and shutdown > cheaper. Why? The problem of startup/shutdown cost and how many cores you have are completely orthogonal. I see no problem in starting N threads at the initialization time, use them throughout the application lifetime and then shut down at the end (or never). The cost of these operations is irrelevant. Make it 10x what it is and I will be still fine. If your favorite programming model involves lots of short-running threads that have to be created and torn down repeatedly, then it has no relation to multicore. It is just a bad resource usage pattern. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4