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!news4.google.com!feeder.news-service.com!newsfeed.straub-nv.de!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: Fri, 26 Mar 2010 19:35:13 +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> <1rn39ttn5pon9$.11n683q5t6itu.dlg@40tude.net> <7b059d0f-791b-4ac9-bf64-c50448ec99f7@b30g2000yqd.googlegroups.com> Injection-Date: Fri, 26 Mar 2010 19:35:13 +0000 (UTC) Injection-Info: feeder.eternal-september.org; logging-data="31529"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+dg9LizkFCACVcNI89MevHzi9ozdz5yAk=" 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:LdtsH1NLZPFJDBatop/2cNgIwtA= Xref: g2news2.google.com comp.lang.ada:10757 Date: 2010-03-26T19:35:13+00:00 List-Id: Maciej Sobczak expounded in news:7b059d0f-791b-4ac9-bf64-c50448ec99f7@b30g2000yqd.googlegroups.com: .. > The difference between application and OS is in the amount of > knowledge about what the software will do and applications tend to > know more than OS in this aspect. Yes. > That is why it is more realistic to have applications allocating their > resources during initialization phase than to see that at the OS > level. I would generally agree with that, unless the cost of resource management was cleverly reduced. > I'm not a big fan of programs that allocate and deallocate the same > resource repeatedly - this is an obvious candidate for caching and > object reuse, where the cost of allocation is amortized. As a general principle this is right. But memory is another resource that sometimes needs careful management. With only 1 thread, you have a heap growing up to the stack and a stack that grows towards the heap. Either stack or heap can be huge (potentially at least), as long as both are not at the same time (overlapping). The moment you add 1 [additional] thread, you've now drawn the line in the sand for the lowest existing stack, and putting a smaller limit on it. This disadvantage is ok for probably most threaded programs, but perhaps not for a video rendering program that might hog resources on both heap and stack sides at differing times. In the end, the application programmer must plan this out, but this is a limitation that I dislike about our current execution environments. I suppose, just increasing the size of your VM address space, postpones the problem until we hit limits again. ;-) > Fortunately, > it is not even necessary for a user code to do that - think about a > caching memory allocator, there are analogies. And the language > standard does not prevent implementations from reusing physical > threads, if they are used as implementation foundations for tasks. > Maciej Sobczak * http://www.inspirel.com >From an efficiency pov, this is all well and good. But if you want maximum dynamic allocation of heap+stack, then you might prefer fewer (if any) pre-allocated threads (implying additional stacks). Warren