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,6ca5f0d94d4c145 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!news.glorb.com!transit3.readnews.com!news-xxxfer.readnews.com!news-out.readnews.com!transit4.readnews.com!panix!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Distributed Computing in Ada Date: Fri, 28 Aug 2009 08:24:30 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <7f8194ed-26d1-4a38-841b-6cb910b10ce4@j9g2000prh.googlegroups.com> <7ea2b1c2-a011-456e-9ec2-10c4ab75ee05@r38g2000yqn.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1251462271 18473 192.74.137.71 (28 Aug 2009 12:24:31 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 28 Aug 2009 12:24:31 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:a/OcvneR535GokbzbawiMfgyMak= Xref: g2news2.google.com comp.lang.ada:8033 Date: 2009-08-28T08:24:30-04:00 List-Id: "Jeffrey R. Carter" writes: > Robert A Duff wrote: >> Well, sort of, but not in a practical way. Ada tasks share memory, and >> there's no way to tell which variables are shared. "Distributed" means >> no shared memory. > > Ada tasks /can/ share memory, but they don't have to. The problem is that the compiler can't know which variables are shared. Maybe no variables are shared, and all communication is via rendezvous, but if the compiler doesn't know that, it's no help. For example: package body P is Global : Integer := 0; procedure Q is begin Global := Global + 1; end Q; end P; Is Global shared? It depends on who calls it. Elsewhere we might have: task type T is entry E; end T; task body T is begin loop select accept E do P.Q; -- Read and write shared variable. ... --etc. end loop; end T; A : array (...) of T; Now we have a bunch of tasks accessing shared variable Global, all correctly synchronized by the rendezvous. But the compiler didn't know it was shared when it compiled package body P. And when it compiled tasks T, it didn't know P.Q modifies any variable. You could do a whole-program / link-time analysis, but that doesn't scale well (Ada was designed to support separate compilation for a reason!). And even that won't always work -- consider possibly-shared variables in the heap, where the compiler can't know what points at what (see halting problem). All in all, in this regard, I'd say Ada 83 tasks are just like the "threads" of various languages and operating systems (Posix threads, Java threads...) -- all these are designed with the assumption of a shared address space. Ada 95 protected types are designed with the same assumption. >...The rendezvous > seems like it would map nicely to message passing. Yes, it is. That's how we did it -- basically, an entry call sends a message, and at the end of the accept, the called task sends a message back to the caller. It's tricky, though -- what happens if one of the entry parameters points into the address space of the caller, either via an explicit access value, or via implicit pass-by-reference? That's bad -- the data really needs to get copied across the network. Note that this was Ada 83, so it predated protected types. >> I actually implemented such a system for Ada 83, where tasks could run >> on different computers. But there were some severe restrictions on >> shared variables. Terminate alternatives are "interesting" in that >> context. > > Yes, there would have to be some mechanism to deal with shared > variables; the simplest would be simply to outlaw access to non-local > variables in tasks if you want to run your program on a distributed > system. Depends what you mean by "outlaw". If you mean "illegal", so you get an error message at compile time, that won't work. You could give an error message at "link time", but only by being overly conservative (that is, outlawing perfectly-OK programs). You could say it's erroneous to access shared variables (so it leads to unpredictable behavior) -- that works fine, but it's obviously not ideal. Or you could implement a distributed shared address space via message passing, but I fear that would be prohibitively expensive. Ada 95's Distributed Systems Annex solves all this mess, by allowing the compiler to know which variables are shared. The unit of distribution is the "partition", not the "task". Usually, no variables are shared across partitions -- but it's important for the compiler to know when that's the case. - Bob