Is Par redundant?

[Folknology]

I have always found the Par{} construct a little odd, but more recently I find it rather pointless let me explain:

Given the move for each thread to be allocated to a core rather than the loose e.g. :

Code: Select all

int main(void) {
  chan c;
  par {
    thread1(c);
    thread2(c);
  }
}

replaced by:

Code: Select all

int main(void) {
  chan c;
  par {
    on stdcore[0] : thread1(c);
    on stdcore[0] : thread2(c);
  }
}

the 'on' identifier now represents start thread, thus the par construct is redundant surely?
It should thus become:

Code: Select all

int main(void) {
  chan c;
  on stdcore[0] : thread1(c);
  on stdcore[0] : thread2(c);
}

Likewise Replicators from :

Code: Select all

# include < platform .h >
port   p [4] = {
   on  stdcore [0]   : XS1_PORT_1A ,
   on  stdcore [1]   : XS1_PORT_1A ,
   on  stdcore [2]   : XS1_PORT_1A ,
   on  stdcore [3]   : XS1_PORT_1A
};
void node ( chanend , chanend , port , int n );
int main ( void ) {
   chan c [4];
   par ( int i =0; i <4; i ++)
      on stdcore [ i ] : node ( c [ i ] , c [( i +1)%4] , p [ i ] , i );
   return 0;
}

Change to:

Code: Select all

# include < platform .h >
port   p [4] = {
   on  stdcore [0]   : XS1_PORT_1A ,
   on  stdcore [1]   : XS1_PORT_1A ,
   on  stdcore [2]   : XS1_PORT_1A ,
   on  stdcore [3]   : XS1_PORT_1A
};
void node ( chanend , chanend , port , int n );
int main ( void ) {
   chan c [4];
   for ( int i =0; i <4; i ++)
      on stdcore [ i ] : node ( c [ i ] , c [( i +1)%4] , p [ i ] , i );
   return 0;
}

Thus Par is surplus to requirement or am I missing something?

regards
Al

[Andy]

I think it is useful when looking at the code from a sequential C perspective... it is clear that the functions inside par{} are running in parallel and anything after it is sequential.

The construct probably stems from PAR/SEQ in occam where you explicitly have to define sequential code after a SEQ.

[Folknology]

I would be inclined to agree if PAR and SEQ were both used through out the programs as in Occam, but they are not, Par can only be used in main and there is no Seq block in xc so it doesn't really make sense, unless you are assuming the developers are coming from an Occam background. To be fair even Occam users would be confused with the use of Par in XC!

The use of 'on stdcore[TARGET]' is in my opinion is much more relevant and direct as it says fork or start a thread here on Target core, the Par wrapper just confuses the hell out of a newbie because it doesn't actually add anything. Also in the case of Replicators adds complexity rather than reusing and existing and familiar 'for(;;)' construct. I think that is particularly true if targeting 'C' programmers rather than Occam programmers.

[oar_some]

Par can only be used in main

This is incorrect, and exactly why par is not redundant as you suggest.

[Folknology]

Apologies

I got confused by this:

A multicore main function may contain only channel declarations, a single par state-
ment and an optional return statement. The on statement may be used to specify
the location of threads only within this function.

So I looked up this from the xc docs

par statements may be used anywhere in a program. Each XS1 device has a limit of
eight threads available on each of its processors, and a program that attempts to
exceed this limit is invalid.

I stand corrected on where Par can be used

But my main point is that Par is still redundant, irrelevant of where it is in a program it is used. "on stdcore[X]" is indicating fork or start thread on X.

And as such that's the point of this thread, is par actually needed?

[m_y]

And as such that's the point of this thread, is par actually needed?

Most abstractions in high(er) level programming languages are not actually needed but some of them are quite useful. Par has the pleasant property of costing you nothing if you don't want to use it.

[Folknology]

Hehe, I agree here, I have seen that many in the languages I have learnt over the decades ;-)

Most abstractions in high(er) level programming languages are not actually needed but some of them are quite useful. Par has the pleasant property of costing you nothing if you don't want to use it.

However in this case I cannot choose to omit par{} as it won't compile ;-)

But for the future it should surely be revisited and perhaps be made optional prior to disappearing totally. This has the added benefit of making the language clearer and less ambiguous over time.. (unike Java for instance)

regards
Al

[Heater]

OK the main() function can have only a single par statement and now a days the "on" is required.

But other functions can be a mixture of parallel and sequential code.
So what about when your code has a mixture of threaded activity and sequential activity?
Something like:

Code: Select all

void someThread(void)
{
    chan c;
    while (1)
    {
        par
        {
            thread1(c);
            thread2(c);
        }

        ...do some sequential statements here...

        par
        {
            thread3(c);
            thread4(c);
        }
}

The you need "par" to delimit things in the same way as yo do for "if", "for", "while" etc.

Notice that no "on" is used here. I'm assuming that functions lower than main don't need it and the threads will run on the core of the current parent thread. Is this true?

[Heater]

Be happy we don't need "seq" to create a sequential series of statements as was required in OCCAM.
I guess that one really was redundant. But probably helped with the formal analysis/verification.

[Folknology]

Notice that no "on" is used here. I'm assuming that functions lower than main don't need it and the threads will run on the core of the current parent thread. Is this true?

Well I have been led to believe that this is not the case, and use of threads without appropriate 'on stdcode[x]' is actively being dissuaded as xc moves forward, that is one of the main reasons for the thread.

Obviously with the use of "on stdcore[x]' the point is mute, it is clear where the threads fork/start