Path: ...!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: fir <fir@grunge.pl>
Newsgroups: comp.lang.c
Subject: Re: call queue and multithreading?
Date: Sat, 23 Mar 2024 10:37:22 +0100
Organization: i2pn2 (i2pn.org)
Message-ID: <utm7sm$2pd90$1@i2pn2.org>
References: <utm6nd$2pbjl$1@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 23 Mar 2024 09:37:26 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2929952"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="+ydHcGjgSeBt3Wz3WTfKefUptpAWaXduqfw5xdfsuS0";
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <utm6nd$2pbjl$1@i2pn2.org>
Bytes: 4005
Lines: 85

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"