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: g2news2.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!news.mixmin.net!feeder.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Warren Newsgroups: comp.lang.ada Subject: Re: Threadpool with priority version 1.1 ... Date: Thu, 25 Mar 2010 17:21:05 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: 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> <7794a413-34e9-4340-abcc-a6568246fc38@h18g2000yqo.googlegroups.com> Injection-Date: Thu, 25 Mar 2010 17:21:05 +0000 (UTC) Injection-Info: feeder.eternal-september.org; logging-data="16263"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+KkWqQJ82y46edUPFNHR6nZ+3fEQ1HJgc=" User-Agent: Xnews/5.04.25 X-Face: &6@]C2>ZS=NM|HE-^zWuryN#Z/2_.s9E|G&~DRi|sav9{E}XQJb*\_>=a5"q]\%A;5}LKP][1mA{gZ,Q!j Cancel-Lock: sha1:hJgzMjmsF7AFoJTPCVugff6QD8w= Xref: g2news2.google.com comp.lang.ada:10741 Date: 2010-03-25T17:21:05+00:00 List-Id: Maciej Sobczak expounded in news:7794a413-34e9-4340-abcc-a6568246fc38 @h18g2000yqo.googlegroups.com: > 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). Yes, I am aware of that option. > 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 That's a rather sweeping statement to make ("bad resource usage pattern"). Unless there are leaps in language design, I believe that is what you will mostly get in automatic parallel thread generation. As humans we tend to think in sequential steps, and consequently code things. The media seems to suggest that we shouldn't have to change our mindset to do parallism (i.e. the compilers should arrange it for us). Certainly that would make a wish list item. I don't know much about Intel's hyper-threads, but I believe it was one approach to doing this (presumably largely without compiler help). So I can't buy into your conclusion on that. Warren