call queue and multithreading?

[fir]

i presented my idea of adding a keyword queue
to c that will build internal queue of function calls
and then run it after the scope of parent function ends


like

void f()
{
queued f1();
queued f2();
queued f3();
}

will do (behind the scene)

internal_queue[0].fp = f1;
internal_queue[1].fp = f2;
internal_queue[2].fp = f3;

for(int i=0; i<internal_queue_top) internal_queue[i].fp()

it aslo should hold the arguments in the queue but i oomitted
it for simplicity (i mean it might be done in few ways and
i dont want to consider now which one is better)

thete is also not fully clear for me when to call the queue,
i assume for now after the parent scope ends but maybe there
would be needed explicit keyword to run it and meybe
c should offer few queues like

queued(1) f1(); //queue number one

such internal queue is good thing for sure imo (or more
caustios to say - seem good for sure)

it gives handy way of decomposition like sai i will calc
mandelbrot code i could write

for(int j=0; j<image_height; j++) queued calc_mandelbrot_vertical_line(j);

and though it not gives much of benefit - it just generates queue of
saj 900 pointers the advantage is 1) it is simple 2) closes
us to paralelisation - as if weare able to run queues in parralel
this all to do it for simple paralelisation

for(int j=0; j<image_height; j++)
queued(1) calc_mandelbrot_vertical_line(j);

run_queue_pararelly(1); //some keyword here needed
//code here 'waits' untill full queue is executed


and thats is - implementation could depend on copmpiler
and hardware manufacturers (it should be run in cpu cores
managed by some manager but maybe also on some hardware
that more resembles gpu channel sets etc)

tghis is in fact probably better thet those kernels i was
writing back then

here above i assume that the queue queued a tasks that are
common ram-write independant.. the question is qhat to
do here with some other tasks that are somewhat colliding

i cannot find hovever for me any exampla good for
consideration for this i mean somewhat colliding tasks that
i could think of to be queued and what i would need to add
yet to help to deal with (manage) that collisions

maybe someone knows such example for consideration?

[fir]

Post by fir
i presented my idea of adding a keyword queue
to c that will build internal queue of function calls
and then run it after the scope of parent function ends
like
void f()
{
queued f1();
queued f2();
queued f3();
}
will do (behind the scene)
internal_queue[0].fp = f1;
internal_queue[1].fp = f2;
internal_queue[2].fp = f3;
for(int i=0; i<internal_queue_top) internal_queue[i].fp()
it aslo should hold the arguments in the queue but i oomitted
it for simplicity (i mean it might be done in few ways and
i dont want to consider now which one is better)
thete is also not fully clear for me when to call the queue,
i assume for now after the parent scope ends but maybe there
would be needed explicit keyword to run it and meybe
c should offer few queues like
queued(1) f1(); //queue number one
such internal queue is good thing for sure imo (or more
caustios to say - seem good for sure)
it gives handy way of decomposition like sai i will calc
mandelbrot code i could write
for(int j=0; j<image_height; j++) queued calc_mandelbrot_vertical_line(j);
and though it not gives much of benefit - it just generates queue of
saj 900 pointers the advantage is 1) it is simple 2) closes
us to paralelisation - as if weare able to run queues in parralel
this all to do it for simple paralelisation
for(int j=0; j<image_height; j++)
queued(1) calc_mandelbrot_vertical_line(j);
run_queue_pararelly(1); //some keyword here needed
//code here 'waits' untill full queue is executed
and thats is - implementation could depend on copmpiler
and hardware manufacturers (it should be run in cpu cores
managed by some manager but maybe also on some hardware
that more resembles gpu channel sets etc)
tghis is in fact probably better thet those kernels i was
writing back then
here above i assume that the queue queued a tasks that are
common ram-write independant.. the question is qhat to
do here with some other tasks that are somewhat colliding
i cannot find hovever for me any exampla good for
consideration for this i mean somewhat colliding tasks that
i could think of to be queued and what i would need to add
yet to help to deal with (manage) that collisions
maybe someone knows such example for consideration?

anyway though i dont know the answer, as i cant state question
as for a moment, i may say that this queue is good thing becouse it
shows a direction - first part - and the rest i think is much easier

for exampel i think if you had such couple of queued fubctions
and they are somewhat dependant they may comunicate by reading its own
variables - write can do a crash but read is safe imo and
such isleted function can just check what his neighbour state is and use
it...instead of thi rather idiotioc waited in loop or mutex it could
maybe eventually put himself at the end of the queue (or his child) -
and this putting child at end would mean "do it later then"

[fir]

Post by fir

Post by fir
i presented my idea of adding a keyword queue
to c that will build internal queue of function calls
and then run it after the scope of parent function ends
like
void f()
{
queued f1();
queued f2();
queued f3();
}
will do (behind the scene)
internal_queue[0].fp = f1;
internal_queue[1].fp = f2;
internal_queue[2].fp = f3;
for(int i=0; i<internal_queue_top) internal_queue[i].fp()
it aslo should hold the arguments in the queue but i oomitted
it for simplicity (i mean it might be done in few ways and
i dont want to consider now which one is better)
thete is also not fully clear for me when to call the queue,
i assume for now after the parent scope ends but maybe there
would be needed explicit keyword to run it and meybe
c should offer few queues like
queued(1) f1(); //queue number one
such internal queue is good thing for sure imo (or more
caustios to say - seem good for sure)
it gives handy way of decomposition like sai i will calc
mandelbrot code i could write
for(int j=0; j<image_height; j++) queued
calc_mandelbrot_vertical_line(j);
and though it not gives much of benefit - it just generates queue of
saj 900 pointers the advantage is 1) it is simple 2) closes
us to paralelisation - as if weare able to run queues in parralel
this all to do it for simple paralelisation
for(int j=0; j<image_height; j++)
queued(1) calc_mandelbrot_vertical_line(j);
run_queue_pararelly(1); //some keyword here needed
//code here 'waits' untill full queue is executed
and thats is - implementation could depend on copmpiler
and hardware manufacturers (it should be run in cpu cores
managed by some manager but maybe also on some hardware
that more resembles gpu channel sets etc)
tghis is in fact probably better thet those kernels i was
writing back then
here above i assume that the queue queued a tasks that are
common ram-write independant.. the question is qhat to
do here with some other tasks that are somewhat colliding
i cannot find hovever for me any exampla good for
consideration for this i mean somewhat colliding tasks that
i could think of to be queued and what i would need to add
yet to help to deal with (manage) that collisions
maybe someone knows such example for consideration?

anyway though i dont know the answer, as i cant state question
as for a moment, i may say that this queue is good thing becouse it
shows a direction - first part - and the rest i think is much easier
for exampel i think if you had such couple of queued fubctions
and they are somewhat dependant they may comunicate by reading its own
variables - write can do a crash but read is safe imo and
such isleted function can just check what his neighbour state is and use
it...instead of thi rather idiotioc waited in loop or mutex it could
maybe eventually put himself at the end of the queue (or his child) -
and this putting child at end would mean "do it later then"

in fact i dont know to much cases for paralelisation, some i can think of:
1) thing like mandelbrot drawing - strightforward paralelisation (separated)

2) raytracing - im not sure but as far as i remember its also
strightforward i mean you can divide screen on pieces each piece
generates rays, and checks the scene collisions

3) rasterisation - also not sure but here input is a big arrays of
triangles (geometry) - probably this input can be divided on parts
the rasterizer multiplies it by camera matrice and projects on 2d
then rasyerises... possibly each of this piece can be rendered into
seoarate frame+depthbuffer than after ar generated those separate
buffers can be "added"

but each of this case seem to be simple do no oportunnity
to test more complex queue scenarios