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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: RFC: Prototype for a user threading library in Ada Date: Tue, 21 Jun 2016 09:34:17 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> <0b853aa8-e542-4f10-bd55-c4e76bb7bf75@googlegroups.com> NNTP-Posting-Host: vFKDMXWEWKqnQQwESBoFfw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:30853 Date: 2016-06-21T09:34:17+02:00 List-Id: On 21/06/2016 04:40, rieachus@comcast.net wrote: > On Friday, June 17, 2016 at 12:46:46 PM UTC-4, Dmitry A. Kazakov wrote: >> On 2016-06-17 18:18, Niklas Holsti wrote: >> >> My take on this problematic is that there cannot exist a solution >> implemented at the library level. All these frameworks maybe fun (for >> the developer) but useless (horror for the end user) when the key >> problem is not solved. That is, the control-flow state (as you said) and >> the stack of the local objects both preserved between scheduling points. >> This can be done IMO only at the language level as co-routines, >> non-preemptive, cooperative, user-scheduled tasks, call it as you wish. > > I've been trying to understand not just the code, but the goal. I > decided to start from a different perspective. What if I had a problem > and wanted to distribute the solution across thousands of processors? > Since I tend to bang my head against NP-hard or NP-complete problems, I > would want a program structure that allowed me to start up at least one > (Ada) task per processor, with enough data to complete, and for the job > creation software to use a very wide tree. A similar reverse tree could > be used to collect results if needed. I have a similar problem. I implement network protocols. A classic implementation is to start one task per client-server connection, or two tasks when the exchange is full duplex. An OS can typically handle a few hundred tasks before it runs out of juice. So the solution is to share a large number of sockets between some few tasks. And so it runs into the problem of an I/O-events-driven design and thus to co-routines. > But to do any of this, I head for the distributed systems annex. It > might be nice to have a simple example of how to do that on top of MPI: > https://computing.llnl.gov/tutorials/mpi/#MPI2-3 (To be honest, using > the C or Fortran bindings is what I have done...) Distributed annex is unusable for massively parallel systems because it is based on RPCs. It is the same problem in its core. Such a system requires asynchronous communication driven by I/O events. Yet the application logic is incoherent with the logic of I/O. In order to bring them together, again, [distributed] co-routines are needed to restore the application view of control flow. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de