Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
Newsgroups: comp.lang.c
Subject: Re: best approach for multithreading (?)
Date: Sun, 1 Dec 2024 15:10:03 -0000 (UTC)
Organization: the-candyden-of-code
Lines: 71
Message-ID: <slrnvkousf.2d4d7.candycanearter07@candydeb.host.invalid>
References: <ddd3a0b59c95b5752b66f46348c96a6f8279d518@i2pn2.org>
Injection-Date: Sun, 01 Dec 2024 16:10:04 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f26f6481281c9784097093ad6805a85f";
	logging-data="2713848"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/YkG8TiRH1yzr1ClZTwY05YL9IAYWENObBKwBEzp1MSQ=="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:iXQ6LmluEtPQN3oexdzLil4KHVE=
X-Face: b{dPmN&%4|lEo,wUO\"KLEOu5N_br(N2Yuc5/qcR5i>9-!^e\.Tw9?/m0}/~:UOM:Zf]%
 b+ V4R8q|QiU/R8\|G\WpC`-s?=)\fbtNc&=/a3a)r7xbRI]Vl)r<%PTriJ3pGpl_/B6!8pe\btzx
 `~R! r3.0#lHRE+^Gro0[cjsban'vZ#j7,?I/tHk{s=TFJ:H?~=]`O*~3ZX`qik`b:.gVIc-[$t/e
 ZrQsWJ >|l^I_[pbsIqwoz.WGA]<D
Bytes: 3545

fir <profesor.fir@gmail.com> wrote at 22:04 this Saturday (GMT):
> [i wropte it soem days back then to eventually post in a place when 
> people can answer this but i dont get idea of such place so i post it 
> here for now]
>
> tell me if you know somethin better approach for multithreading
> than this
>
> i mean i got discovered soem approach for multithreadng
> (i mean scheme how it probably should be done) and i wonder
> if there is something better than this (in real world)
>
> the appriach is based on call queue and needs (at least
> as a base) two keywoards 'adq' (add queue) and 'runq' (run queue)
> ewentually 'runqs' (run queue sequantially) 'runqp' (run queue in
> parrallel)
>
> adq just adds a given adress of a function and its arguments
> in queue which is close to stack, say
>
> for(int i=0; i<5; i++)
>   adq__ foo(i);
>
> stores
>
>
> foo, 0
> foo, 1
> foo, 2
> foo, 3
> foo, 4
>
> (40 bytes if foo is 32 bit adress, and i is 32 bit int)
> in ram
>
> runq
>
> then runs it (iterates and runs the functions)
>
> (both adq and runq are better implemented on language level,
> though they also probably can be implemented in some library)
>
> the thing is the runq dont need to run the things on one core
> and sequentially but it can just run the queue on as many cores
> as are avaliable
>
> no problem i think if those queued calls are not conflicting one witch
> another (like foo is draw_line_of_mandelbrot(i); ) but if the calls may
> be somewhat conflizting (on ram writes) there is an optio to add
> to addq also a number assigned to each call which will denote/mark
> this call to be not conflicting witch another call if the numbers are
> different and eventuallt be conflicting if the numbers are the same 
> (like "1")
> then the cals of the same group should be run on one core in sequential 
> but the
> other groups can each be called on its own core
>
> i did not used multithreading more than couple of days in my life
> so i know it slight but i never liked what i used to much and this
> approach seem to me best of what i heard..
>
>
> so is it he best approach or there is something better?
>
> /fir


There's a standard library for multithreading.
https://www.man7.org/linux/man-pages/man7/pthreads.7.html
-- 
user <candycane> is generated from /dev/urandom