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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,8e11100f675ea2df X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.66.84.164 with SMTP id a4mr3637497paz.26.1357013081293; Mon, 31 Dec 2012 20:04:41 -0800 (PST) Path: s9ni75449pbb.0!nntp.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Mon, 31 Dec 2012 22:04:40 -0600 Date: Mon, 31 Dec 2012 19:58:58 -0800 From: Charles Hixson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: asynchronous task communication References: <1c2dnd5E6PMDR33NnZ2dnUVZ_sednZ2d@earthlink.com> <50e18094$0$6583$9b4e6d93@newsspool3.arcor-online.net> <7NednS4s2oukfXzNnZ2dnUVZ_oadnZ2d@earthlink.com> In-Reply-To: Message-ID: X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 216.244.16.210 X-Trace: sv3-BIJDWSz+rbFrAhMJGvf3Tr0kvoXF309AG4CcK6sB+uNyGj8XXlBwgwEXVgheYBzFpg3KpNA6DKqmrq3!HXSufhfCOsb2lw204+ysqOmZeDiFeCnRI0Dcjc/VAiFNMghs1ZTxy9lXq3Lso6SMWS2pxwrWzYbg!Qk1UNIx9bSBDfCrJosfqxA== X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 4676 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-12-31T19:58:58-08:00 List-Id: On 12/31/2012 02:15 PM, Randy Brukardt wrote: > "Niklas Holsti" wrote in message > news:aked87Fpfc1U1@mid.individual.net... >> On 12-12-31 20:52 , Charles Hixson wrote: >>> Thank you for your answer. >>> >>> The problem with that solution is that I've been advised that I >>> shouldn't have many more tasks than available cores, >> >> IMO that advice is useful only if your application logically needs fewer >> tasks than you have cores, but you want to increase the number of tasks >> in order to have more cores running in parallel. It can then make sense >> to replicate some of your tasks (the "pool of worker tasks" idea), so >> that several identical tasks work in parallel on the same kind of jobs, >> or to split some of your tasks into smaller tasks that work in parallel >> on different consecutive steps of a job (the "task pipeline" idea). >> >> As you increase the number of tasks in this way, performance increases >> because more tasks can be run in parallel, until you reach one of two >> bounds: >> >> 1. new tasks have nothing to do, and just wait for input or for some >> other task to do something, or >> >> 2. all cores are already busy, on average, so new tasks must wait for a >> core to become free. >> >> Case (1) means that your application is somehow "I/O bound" or >> "communication bound", while case (2) means that your application is >> "computation bound". The advice you got applies to case (2). >> >> But if your application logically needs more tasks than there are cores, >> because of the way tasks communicate and interact, there is absolutely >> no reason to limit the number of tasks to the number of cores, or >> anything related to the number of cores. There are applications on >> single-core processors with hundreds of tasks. >> >> So if you need an extra task, or ten extra tasks, in order to decouple >> the timing of some other tasks from each other, go ahead. > > Right, I touched on this last week. The issue is the amount of CPU load for > each task, not the raw numbers of tasks. > > Most tasks spend most of their time blocked (the mailbox tasks surely are in > this category). Such tasks don't contribute much to the CPU usage and surely > shouldn't be counted as "using up a core". Tasks that are intended to be > running most of the time do "use up a core", but even then, you may be > better off structuring your program with more tasks. > > Someone else touched on it, but premature optimization is a very common > evil. And that extends just as much to the use of tasks as it does with > anything else. > > Randy. > > For the application I'm designing, blocking is VERY evil, and also can't be avoided. Think of it as a neural net with feedback circuits. Also, to model it correctly I'd need millions of tasks, and I'd still need asynchronous communication to avoid deadlock. OTOH, I think I've found a solution: For each cell, implement it as a record of two protected objects. One of which is the cell, as previously conceived, and the other of which is a mailbox. The mailbox would never block for long. I am worried a bit about the increase in RAM requirements, but perhaps that can't be avoided. At least it allows nearly non-blocking communication.