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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: GNAT and Tasklets Date: Thu, 18 Dec 2014 16:33:05 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <455d0987-734a-4505-bb39-37bfd1a2cc6b@googlegroups.com> <8277a521-7317-4839-b0b6-97f8155be1a4@googlegroups.com> <9e1d2b9f-1b97-4679-8eec-5ba75f3c357c@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1418941985 7516 24.196.82.226 (18 Dec 2014 22:33:05 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 18 Dec 2014 22:33:05 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:24126 Date: 2014-12-18T16:33:05-06:00 List-Id: wrote in message news:9e1d2b9f-1b97-4679-8eec-5ba75f3c357c@googlegroups.com... ... >And if the compiler chose only one implementation, like always a kernel >thread >for a task, which is the case now, I have to say that it is not a mature >implementation of tasking. In which case I think you will have an approximately 0% chance of ever encountering your idea of a "mature implementation of tasking" in an Ada compiler. Ada tasking is far too complex to implement it more than once, especially with all of the potential race conditions and deadlocks that mixed implementations would face. There is no such thing as a "lightweight Ada task". The syntax is heavy, the semantics is heavy (separate stack, exception handling, finalization, termination), and as a correlary, the implementation is heavy. >Finaly, I really hope that the new version of the langage will keep Ada >simple ... That ship sailed with Ada 95, if it ever was true at all. Besides, you confuse the appearance of simple (that is simple to use, simple to learn) with simple in language terms. My_Vector(I) := 10; looks simple, but if My_Vector is a vector container, what actually happens is anything but simple. But so what? Only people that have to write/debug containers ought to care; we've made usage simple at the cost of making creation harder. Similarly, for I in parallel 1 .. 10 loop ... end loop; looks and feels simple, even though what would have to happen under the covers to implement that is anything but simple. >and add "intelligence" in compilers and not add different new features with >: >- tasks for kernel threads >- coroutines or tasklets for user-level threads >- jobs for lightweight threads, >because this would be a major conceptual regression. I believe that aspects >on tasks could be an inelegant but decent way to solve the problem. You are still thinking way too low-level. Creating a parallel program should be as easy as creating a sequential one. There should (almost) be no special constructs at all. Ideally, most programs would be made up of parallel loops and blocks, and there would be hardly any tasks (mainly to be used for separate conceptual things). Writing a task correctly is a nearly impossible job, especially as it isn't possible to statically eliminate deadlocks and race conditions. It's not something for the "normal" programmer to do. We surely don't want to put Ada's future in that box -- it would eventually have no future (especially if very-many-core machines become as common as some predict). In any case, there won't be any major upgrade of the Ada language for at least another 5 years. The upcoming Corrigendum (bug fix) has few new features and those are all tied to specific bugs in the Ada 2012. So I wouldn't wait for language changes to bail you out; Brad's libraries are the best option for now. Also please note that language enhancements occur through a process of consensus. Most of the ARG has to agree on a direction before it gets into the language standard. You should have noted by now that pretty much everyone who has answered here has disagreed with your position. It's highly unlikely that the ARG would invent language changes that the majority of the Ada community think are the wrong direction. That's especially true as Brad and I are on the ARG and are working on these language changes. The ARG has already voted to continue work in the direction that the "Group of Four" proposed (which is similar to what I would propose if it was up to me). I'd be very surprised if we made a u-turn at this point (especially as the proposals fit well into the existing framework of Ada and most are useful outside of the narrow area of parallel operations). This will be a big job and it will be a long time before we get to the real nitty-gritty of these proposals (the problems will be in the details, not the broad outline -- anyone can do that!). Anyway, you can swim against the current if you like, but you most likely aren't going to get anywhere doing that. Randy.