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.89.39 with SMTP id bl7mr8477615pab.33.1357498037799; Sun, 06 Jan 2013 10:47:17 -0800 (PST) From: Brian Drummond Newsgroups: comp.lang.ada Subject: Re: asynchronous task communication Date: Tue, 1 Jan 2013 10:38:47 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <1c2dnd5E6PMDR33NnZ2dnUVZ_sednZ2d@earthlink.com> <50e18094$0$6583$9b4e6d93@newsspool3.arcor-online.net> <7NednS4s2oukfXzNnZ2dnUVZ_oadnZ2d@earthlink.com> <7cudnYloBfQDw3_NnZ2dnUVZ_rKdnZ2d@earthlink.com> Mime-Version: 1.0 Injection-Date: Tue, 1 Jan 2013 10:38:47 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="dfff62e1e537b55df42008571c03e0fe"; logging-data="27442"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19NtNj/Eswm+GZDTu3ytJbC3w6uauIymDA=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:85PBWF5Ag4m165QbSBmxHWCyrqg= Path: s9ni86197pbb.0!nntp.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.mccarragher.com!news.grnet.gr!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail X-Received-Bytes: 6271 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: 2013-01-01T10:38:47+00:00 List-Id: On Mon, 31 Dec 2012 19:51:36 -0800, Charles Hixson wrote: > On 12/31/2012 01:09 PM, Niklas Holsti wrote: >> On 12-12-31 20:52 , 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. This is sounding a lot like the VHDL model of inter-process communication using (VHDL's version of) signals, with delta cycles to allow further messages causing further messages and so on... of all the logic simulation languages, is unique in managing to maintain determinism in what looks from the outside like asynchronous message passing. It also avoids the whole mess of "blocking" vs "non-blocking" assignments that plagues the other big contender... > 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. VHDL has a different model, avoiding the duplication and copying. The basic units are the process (which resembles an Ada task or C program) and the signal. Each process can be woken either by an event on its "sensitivity list" or an event it is waiting for. Then it runs to either completion (in the former case) or an explicit "wait" such as "wait for some_event" in the latter case. During its entire run, (which takes notionally zero time) it may assign to signals, but the signal values it sees are frozen at their initial values. The new assignments don't actually happen at this stage; signal assignments are known as "postponed assignments". If a process assigns several times to the same signal, the last assignment wins. (Like Ada tasks, processes can have variables, and they follow the usual assignment rules) Only when all processes are suspended will the postponed signal assignments happen. These assignments are events; they schedule selected process to be woken in the next delta cycle. Then the simulation time advances by one delta cycle, and finally all those processes are woken - seeing new, but now frozen, signal values. This process repeats until a delta cycle occurs in which no process is scheduled. (If this does not happen, there is a "combinational loop" which is unwanted in VHDL!). Now real time can be advanced by a tick (femtosecond, nanosecond, etc) until a timed event or external input happens. A combinational loop might be a <= not a; -- loop; "<=" is signal assignment however a <= not a after 2 ns; -- no loop is not a combinational loop (because the "after" clause schedules an event in the future. (This is a model of an oscillator!) This may sound inefficient, but the delta cycle model guarantees that no matter the order of execution of processes within a delta cycle, or the order of signal assignments between them, the result is the same. You might map VHDL processes on to your cells, and signals to your "not- neurons". There might be a few Ada tasks (or even a 1:1 mapping) running processes until the scheduled-process-queue is empty. Then run the corresponding list (or lists : one per task) of postponed assignments. > 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. I have described the VHDL model because it may offer a different perspective on your problem rather than as an immediately applicable solution to it. However it is a successful model with benign formal properties and breaks the requirement for blocking on new signal values, (admittedly, by blocking until the next delta cycle instead!) > (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. The VHDL model could be seen as a central postmaster; delivering mail between each delta cycle. But it certainly doesn't need to be single- threaded! - Brian