0

I'm working on a debugger, using Chapel programming language. In my code I need to use a coforall loop, but unfortunately, I can't find a way to make the parallel iterations to be executed in sequence.

This is a part of my code:

coforall i in 1..n by -1 do
{  
   middle = ( ( _delta[i]._sub.length ) / 2 ) : int;   
   if( middle != 0 )
   {  
       _delta[2*i  ]._sub=_delta[i]._sub[1+middle..];
       _delta[2*i-1]._sub=_delta[i]._sub[..middle];
   }
   ...
}

as you can see I need the iterations of this loop to be executed in parallel and in a backward sequence.

Is there any way to do so?

user3666197
  • 1
  • 6
  • 50
  • 92
mohammadreza
  • 9
  • 1
  • I'm having some trouble understanding the question. What do you mean by "executed in sequence"? Obviously you could write this portion with a 'for' loop, and that would run the iterations in order. What are you trying to achieve with `coforall` ? 'coforall' makes each of the iterations 1..n run in a separate task - why do you want that? – mppf Jul 26 '17 at 13:34
  • Missing all information what precedes `coforall ...` in your post. Would you mind to **read about how to ask the MCVE-based questions** ? StackOverflow encourages users to present a **M**inimum ( efficiency ) + **C**omplete ( self-contained ) + **V**erifiable ( ready for re-runs ) + **E**xamples ( a full example, with all details+data, to allow for re-testing ) of code, that you struggle to make work.The best next step is to learn about this Community practice+ **revise & complete your MCVE above**. Anyway, welcome in this great Community of Knowledge & become our active, contributing member. – user3666197 Jul 26 '17 at 17:23
  • Like @mppf, this question is not clear to me: Why do you say you need the iterations of this loop to be executed in parallel if you need them to execute in a particular order? – Brad Aug 07 '17 at 14:58

1 Answers1

0

A general rule

A code-section, that is to be executed in parallel ( a PAR-type of process scheduling ), by definition, provides no means so as to become executed on any infrastructure of hardware resources in any particular "order" ( like additionally enforcing some kind of a SEQ-type of process scheduling ), including a "reverse-(backward-stepping)-order" et al.

As there is no such even number to be also odd at the same time,
there is no chance for any PAR processes-scheduling to become also SEQ at the same time.

Specific coordination tools for "ordering" task execution still possible

For indeed a special purpose, there are means -- a.k.a. synchronisation primitives -- that could provide a blocking step, so that one part of a computation has to explicitly wait until it receives a message / a value / another kind of a mutual synchronisation impulse from some other process ( a task or a part of a more complex, distributed-system computation graph ).

In all cases a carefull algorithmisation is a must, as blocking states, in principal, could and will devastate all benefits a parallel code-execution may provide.

For details, read about Synchronisation Variables.

Epilogue

In any case, a design, that has to resort to block ( using any kind of a barrier, or waiting for a synchronisation variable, or expecting a message from a CSP-channel et al ) ought be the very last option, if all other Computer Science tools and refactoring efforts have failed to provide any better, and as much PAR as possible, algorithmisation. Besides the blocking, per-se, the Amdahl Law ratio goes steeply down, back to a performance of a pure SEQ schedule.

Serious HPC is not based on using wait-states, but the very opposite.

user3666197
  • 1
  • 6
  • 50
  • 92