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: 103376,8e11100f675ea2df X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.66.86.73 with SMTP id n9mr7205330paz.17.1357064865486; Tue, 01 Jan 2013 10:27:45 -0800 (PST) Path: s9ni76486pbb.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: Tue, 01 Jan 2013 12:27:44 -0600 Date: Tue, 01 Jan 2013 10:21:57 -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> <7cudnYloBfQDw3_NnZ2dnUVZ_rKdnZ2d@earthlink.com> In-Reply-To: Message-ID: X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 216.244.16.210 X-Trace: sv3-WTGCo7W13zmCh905XsZoCaNU6R4um6YnmmeFQo0iYKLWLyjuJZcZy40MlaoC96LvWDtR9bKGGI3WDtI!DseKFHXVnC+priYcJARmlP6u73PMWZgrZMIpn9AKNsLQgKwc61l1GaGdEVwwoHfgBowtSptnQIzW!rl74SWBdtyLxOIZ3d8bRpA== 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: 5578 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2013-01-01T10:21:57-08:00 List-Id: On 01/01/2013 04:32 AM, Jeffrey Carter wrote: > On 12/31/2012 08:51 PM, Charles Hixson wrote:> >> 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. > > I actually wrote such a thing in Ada 83, a tasking implementation of a > neural network with feedback connections. Each node was a task, and any > 2 nodes which were connected had a bounded, blocking queue of length 1 > between them. There were cycles in the network (feedback), but this > structure worked well and did not deadlock. Being Ada 83, each queue was > also a task. There were fewer than 100 total tasks, but then this was a > 286-class DOS computer with about 1 MB of RAM, and it could have handled > more such tasks; I never tested to determine the maximum it could run. > On a modern, multi-core processor, and using protected objects for the > queues, I doubt that a million nodes would be a problem. > > I don't know whether such an approach would work for your problem; we > used a static network layout, for example, so adding nodes was not > considered. > > At the time I wrote that network, most people writing concurrent S/W > would have told me that such a design would not work and I would have to > use a cyclic executive. My experience, and that reported in every paper > by people who used Ada(-83) tasks as intended, was otherwise. Such > people were writing unnecessarily complex code because of premature > optimization. Modern Ada S/W engineers like you and me would never make > such an error, would we? > It sounds like we came to the same basic answer. And your prior experience augurs well. FWIW, premature optimization is a difficulty, and hard to avoid, but if you don't evaluate efficiency, you can't be sure the basic design will work usably even if the code is correct. I'm planning on allowing multiple messages in the mailbox, though. My current though is to split the cells by id# to allot them to tasks, and cycle through the net. The first thing each cell will need to do on being activated is handle it's old mail. Mail sent on one cycle will then usually not be acted upon until the next cycle. I'm undecided as to whether or not to include a cycle count, so as to enforce that implicit regularity. It seems as if I shouldn't need to, as the order of cycling is deterministic, even if what is done isn't. P.S.: Ada is NOT the first language that I looked at when trying to solve this. I really preferred a language with a garbage collector, and where strings didn't default to an inflexible length. (And where they defaulted to utf-8. And where binary files could have header records without a lot of effort. And ...) But I kept running into problems with the way they handled shared memory between tasks. Either they were too protective, or much too wide open. Ada is the only language that has appeared to allow me to construct the memory handling protocol I want, without simultaneously making it totally unguarded. (Or not doing huge amounts of copying of RAM between tasks, which would result in some copies holding stale data.) I must have looked at 10 different languages. Of the other languages I looked at, only Erlang appeared to handle things in the way that I need, and I have trouble wrapping my mind around the way Erlang does things. (I started my programming life with Fortran, and I'm a bit inflexible in the direction of Haskell and Erlang.) So when I look into "How should I implement this?", I'm really evaluating what I can do in the language. And unfortunately it's got to be an evaluation made without really knowing the language well. So I'm really pleased that the way I thought could be done in Ada is confirmed by your report of doing it successfully in an earlier version.