[Cplex] Parallel Manager and More

Herb Sutter hsutter at microsoft.com
Thu Jun 20 23:25:47 CEST 2013

Re (3), don't sell C short -- C _is_ the portable systems/OS language.

So I agree this work is very important, and the most appropriate place to do it is in C, and in this study group, as a focus where liaison experts from C++ and Ada can also contribute.

I would strongly encourage you to consider tackling this very important problem as an immediately- and long-term-useful topic that seems to fall more or less directly under your current charter -- it has certainly come directly out of it!



> -----Original Message-----
> From: cplex-bounces at open-std.org [mailto:cplex-bounces at open-std.org]
> On Behalf Of Nelson, Clark
> Sent: Thursday, June 20, 2013 1:27 PM
> To: cplex at open-std.org
> Subject: Re: [Cplex] Parallel Manager and More
> I have three things to say about the general topic of tunable and
> interoperable run-time support for parallel programming.
> (1) I believe it's very important.
> (2) I have enough ignorance about it to sell wholesale, so I'm virtually certain
> that I have nothing of any technical substance to contribute towards it.
> (3) I suspect that it would make more sense to work on it in an SC22 context,
> rather than a WG14 context. (It's possible that my personal ignorance is
> contributing to my impression that it should be done somewhere else, but
> the topic certainly transcends C and C++.)
> Clark
> > -----Original Message-----
> > From: cplex-bounces at open-std.org [mailto:cplex-bounces at open-
> std.org]
> > On Behalf Of Stephen Michell
> > Sent: Thursday, June 20, 2013 11:33 AM
> > To: cplex at open-std.org
> > Subject: [Cplex] Parallel Manager and More
> >
> > This took a while to respond because I in Europe at stds meetings with
> > sometimes marginal email access.
> >
> > I want to address Daryl's comments about parallelism manager, etc.
> >
> > First a qualification: I would like us to be careful not to call it
> > the "Ada model". Right now it is a model that the 3 of us (Miguel,
> > Brad and myself) have presented unofficially to Ada Europe and more
> > officially to the 16th International Real Time Ada Workshop (IRTAW
> > 16). It certainly generated some interest, but we also took some
> > cannon fire across our bows.  I'll discuss some of the issues later.
> >
> > We submitted the Ada Europe paper end November, and our thinking
> > evolved after that first paper. In particular, Parallelism Manager and
> > Worker Task (thread in C/C++/POSIX) Pool Manager. The job of the
> > Parallelism Manager is to manage the application of the concurrency
> > for each Parallelism OPportunity (POP).
> > The Parallelism Manager has no Tasks to schedule on his own. This is
> > very much along the lines of Darryl's separate parallelism managers.
> >
> > The Worker Task Pool Manager manages a single collection of Tasks that
> > will be the worker tasks that execute the Strands for as many POPs as
> > need the service. There can be a single Worker Task Pool Manager or
> > there can be more than one: the Tasks in a managed pool of Tasks can
> > be created dynamically as needed, can be fixed, or can be one per cpu.
> >
> > The point of the above is that there can be multiple pools of tasks.
> > This is particularly useful when preemption and priorities are
> > involved. If a Task reaches a POP and invokes the Parallelism Manager
> > associated with that POP, it needs worker tasks at the same priority.
> > One way to do this is to change the priority of each Worker as it
> > collecting work. Another way is to have pools of workers at each
> > priority.
> >
> > Someone complained about the single queue. In our model, there will be
> > 1 queue for each pool of ready worker tasks. There is no efficiency
> > issue because it truly is FIFO,
> >
> > I have a few things to say about blocking. Originally in our model, we
> > followed the CILK plus model and were permitting Strands to block. One
> > shot across our bow was that IRTAW 16 abhors blocking in such cases.We
> > note, however, that some parallel algorithms do not work without
> > blocking (for instance when you do a parallel->serial->parallel and it
> > is important that the 2 parallel pieces work on the same data). Our
> > conclusion is that Strand blocking is one of those issues that needs a
> > configuration setting.
> >
> > Note that we do not actually say that the workers will be tasks, or
> > how they are scheduled, unless the programmer takes charge and binds
> > his own parallelism manager and worker task pool manager(s) to the
> > program. Until then the compiler and runtime is free to do as
> > necessary.
> >
> > Hope that helped.
> >
> > ...stephen
> _______________________________________________
> Cplex mailing list
> Cplex at open-std.org
> http://www.open-std.org/mailman/listinfo/cplex

More information about the Cplex mailing list