Re: call queue and multithreading?

fir wrote:

>
>
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"