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.73.134 with SMTP id l6mr6145204pav.0.1357012639226; Mon, 31 Dec 2012 19:57:19 -0800 (PST) Path: s9ni75441pbb.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 21:57:18 -0600 Date: Mon, 31 Dec 2012 19:51:36 -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: <7cudnYloBfQDw3_NnZ2dnUVZ_rKdnZ2d@earthlink.com> X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 216.244.16.210 X-Trace: sv3-weL2HFxVTs6AUrNdQwtvcTgpwVkhVEYjGf0nbXbt11G5VQRjB+pDBrBwPk2vhexen71yqfZz7r5XhWt!VrjCyb3gKRhxhoeNUO9+YRKZnNKStehvbEKITOoMflLvpzdJM+0gmm3IlXaaCZKKXiJr1BJ6Ency!8oxmCwjaN44Q+vwYxPDUJg== 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: 5573 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-12-31T19:51:36-08:00 List-Id: On 12/31/2012 01:09 PM, Niklas Holsti wrote: > 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. > My application logically "needs" thousands or millions of tasks. But this is clearly impractical, so I'm trying to work around it. The application is clearly going to be "communication bound". OTOH, even with millions of separate cores, I'd still need asynchronous communication. FWIW, you can think of what I'm doing is a neural network simulation. There are reasons why that isn't quite accurate, but it's close. And each message is likely (but not certain) to get a reply and may also cause further messages to be sent on. Occasionally new nodes will be added to the net. So logically, each "cell" should be a separate task, but even so asynchronous communication is needed to avoid deadlock. Since I can't model cells as tasks, I'm planning on modeling them as protected variables. Even this may be too limiting, because of the requirement for asynchronous communication. Particularly since protected variables are passive, rather than active, so each one is going to need to wait for a task to activate it. But this appears to be quite likely to interfere with normal execution. The classic answer is to have two copies of the network and to cycle through cone copying it and state changes into the second. Then, at the end of a cycle, reverse it. This requires the whole thing to be copied in each cycle, even the parts that haven't changed in this cycle. I'm trying to avoid that, but I may not be able to unless I can break this requirement for blocking. P.S.: Yes, there are slick ways to minimize the amount of copying needed. If I must take that approach, I'll be using dirty flags, deltas, changed-in-cycle-# etc. But that's NOT an approach that is at all appealing, and it doesn't model the process I'm trying to simulate at all well. Maybe I'll need to do it as a single threaded application. (The more I look at a central postmaster, the less desirable it looks. But perhaps I can have a postmaster attached to each cell, or maybe the cell should be attached to the same record as the mailbox. Then for each cell there'd be an item on the heap that had two protected items: 1. the mailbox and 2. the cell, so sending a message to the cell wouldn't block on the cell being busy, and also wouldn't block on another cell being sent a message at the same time. Perhaps that's the way the thing I was hoping was built-in would have been implemented.)