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,3f60acc31578c72b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news4.google.com!news.glorb.com!logbridge.uoregon.edu!canoe.uoregon.edu!newsfeed.news.ucla.edu!ihnp4.ucsd.edu!sdd.hp.com!news-pa1.hpl.hp.com!news.compaq.com!newsfeed1.sea.pnap.net!newsfeed.pnap.net!brmea-news-1.sun.com!news1brm.central.sun.com!not-for-mail From: Ole-Hjalmar Kristensen Newsgroups: comp.lang.ada Subject: Re: question about tasks, multithreading and multi-cpu machines Date: 16 Mar 2006 11:23:46 +0100 Organization: Sun Microsystems Message-ID: References: NNTP-Posting-Host: khepri06.norway.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news1brm.Central.Sun.COM 1142504628 13418 129.159.112.195 (16 Mar 2006 10:23:48 GMT) X-Complaints-To: usenet@news1brm.central.sun.com NNTP-Posting-Date: Thu, 16 Mar 2006 10:23:48 +0000 (UTC) User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:3378 Date: 2006-03-16T11:23:46+01:00 List-Id: Actually, I think the Ada task concept very closely match the way the term task is used in programs for project planning and organizers. An Ada task definition really says what needs to be done, it does not consider the mapping to OS processes or threads, only the steps to get the job done, and the interfaces to other tasks. A task may not terminate before its sub-tasks terminate. Much like the planning stage of a project, I would say. Luckily, you do not have to hunt for resources or map tasks to threads or processes, the compiler and run time system does it for you. Also observe that the specification of protected types is such that it is possible to run code which is realted to two different tasks in the same thread. So I would say that really, Ada tasks *are* logical tasks, not threads or processes. If you think about Ada tasks as communicating sequential (logical) processes, it is perhaps easier to see what I mean. If you would like more interesting food for thought, have a look at the Occam language. You have to explicitly tell the compiler if you want things to be done sequentially, otherwise it is free to run your statements in parallel :-) >>>>> "MS" == Maciej Sobczak writes: MS> Jeffrey Creem wrote: >> Actually, threads is misleading since threads are just tasks minus >> rendevous. It all just depends on your perspective. Since Ada had >> tasking before (most) unix had threads I think Unix got the name >> wrong :) MS> In my humble opinion, Ada got it wrong in the first place. MS> {Pre-flame note: below is a very informal description of how I think MS> about these terms while designing/programming/etc., not how they are MS> defined in any language/system/etc. standard.} MS> What's funny, the terminology is correctly used in even simplest MS> programs for project planning, organizers, and such. MS> The "task" is something that needs to be done. It's an objective, or a MS> goal to achieve. (I'm not an English native speaker, but my MS> dictionaries seem to confirm this.) MS> To actually perform any given work, some kind of "resource" is MS> needed. Whether it is a human resource or a computing resource does MS> not matter - MS> what's important is that this "resource" is treated as an *ability* to MS> perform work. What's even more important is that there might be unused MS> resources lying around, which can be just used to perform some work if MS> they are available. MS> Now, "thread" is a software resource that represents the ability of MS> the system to do some work. MS> The difference between "task" and "thread" is that "task" is something MS> to do, whereas "thread" is a way to do it. MS> The tasks in Ada do not match any of the above. Other languages (for MS> example Java) also got it wrong, by treating threads as objects or MS> even by allowing a programmer to "subclass" or "specialize" a thread MS> class. None of the languages that I'm aware of allows me to treat MS> tasks and threads as they really are, which means that everybody got MS> it wrong in one way or another. :) >> So, the only thing I am trying to say here is that people seem to >> assume that task, thread and process have some formal definition >> that is all powerful. This is not true. MS> Right. MS> -- MS> Maciej Sobczak : http://www.msobczak.com/ MS> Programming : http://www.msobczak.com/prog/ -- C++: The power, elegance and simplicity of a hand grenade.