Is Par redundant?

[Folknology]

Perhaps another language example would help:

Imagine in java that you could no longer do this :

Code: Select all

thread1.start();
thread2.start();

and rather instead were forced into:

Code: Select all

par {
  thread1.start();
  thread2.start();
}

How helpful would that be? what value does that add?

With XC we know we are dealing with concurrency we expect it as part of the language, thus it should be readable directly in that fashion.

And yes I'm really sorry bringing up such a crappy language to show that, there is no apologies for using java here, it was just to make a point ;-)

[f_petrini]

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.

The on-statement is only allowed in the main function. Specifying what core to run a thread on would make no sense anywhere else since code running on one core can't start a thread on another core.

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

I don't believe it's that obvious.
You still need to enclose the threads in a block for the compiler to know what threads to run in parallel.
Consider this slightly modified version of Heaters example:

Code: Select all

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

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

        ...do some sequential statements here...
}

This would not be possible with only the on-statements...

[Heater]

I'm not sure I get your point. With your example you have kept the ".start()" parts. But with par there is no need for them any more. So the par vs bla.start seems about quits in terms of syntactic overhead and uglyness.

In the days of OCCAM one would could have parallel execution of statements that are not function calls:

Code: Select all

par
  a = some_expression
  b = some_expression

as opposed to sequential execution of statements.

Code: Select all

seq
  a = some_expression
  b = some_expression

Excuse the syntax which is probably not quite right, my memory of OCCAM is fading.

So here "par" and "seq" are essential.

Now assuming we can have "par" without the "on stdcore" stuff then "par" is still required to differentiate from sequential calls.

I have to get home and fire up my XDE to check this out.

P.S. Is it not so that the ".start()" business only comes about when you have an object oriented language with threads where you need to have a method (start()) to run on the thread differentiated from all the other objects methods.

[Folknology]

Ok I think I'm starting to get what you mean. Let me annotate what is meant to happen because of the par blocks

Code: Select all

void someThread(void)
{
    chan c;
    while (1)
    {
        par
        {
            thread1(c);
            thread2(c);
        }
        // don't start these threads until the previous threads have completed
        par
        {
            thread3(c);
            thread4(c);
        }
        // Don't do these sequential things untill all of the previous threads have completed
        ...do some sequential statements here...
}

Basically the Par{} is blocking in these examples, is that what I am missing here?

[f_petrini]

Correct... I think this section describes it clearly:

The four statements inside the braces of the par are run concurrently as four separate
threads using fork-join parallelism: at the opening brace { the parent creates three
more threads; each of these threads then executes a function; and at the closing
brace } the parent waits for all functions to return before continuing.

[Folknology]

This is also therefore a misleading statement in the XC manual on the same page

For multicore programs, all ports and threads must be explicitly prefixed with on.

if your example is correct then this statement is of course untrue.

[Heater]

I think you are right on the button there.

This all comes out of the ideas of concurrent sequential processes (CSP)

If we had such hardware that there was gigantic amount of possibility to perform operations in parallel. Say we had as many giga processors as we have bytes or RAM now a days. Or perhaps the resulting code ends up as a logic design, an FPGA say. The you could write:

Code: Select all

a = 2
b = 3
c = a * b
d = a / b

Or for possibly speeding up the last two staments:

Code: Select all

a = 2
b = 3
par
{
    c = a * b
    d = a / b
}

Languages like VHDL for logic design have other ways to express par.

[f_petrini]

Yes, and the section below states:

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

So clearly conflicting statements...

[Folknology]

And in main for example it serves no purpose since you can't have multiple Par{}s. but maybe it would be more clear with:

wait {
thread1();
thread2().
}

;-)

[Folknology]

Oh and you won't be able to use that same channel c on all 4 of those threads of course ;-)