Re: best approach for multithreading (?)

From	candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
Newsgroups	comp.lang.c
Subject	Re: best approach for multithreading (?)
Date	2024-12-01 15:10 +0000
Organization	the-candyden-of-code
Message-ID	<slrnvkousf.2d4d7.candycanearter07@candydeb.host.invalid> (permalink)
References	<ddd3a0b59c95b5752b66f46348c96a6f8279d518@i2pn2.org>

Show all headers | View raw

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

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

best approach for multithreading (?) fir <profesor.fir@gmail.com> - 2024-11-30 23:04 +0100
  Re: best approach for multithreading (?) candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-12-01 15:10 +0000
    Re: best approach for multithreading (?) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-12-01 15:45 +0000
      Re: best approach for multithreading (?) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-01 15:54 +0000
        Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-01 15:00 -0800
          Re: best approach for multithreading (?) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-03 17:48 +0000
            Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-03 12:24 -0800
            Re: best approach for multithreading (?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-12-05 19:09 -0500
              Re: best approach for multithreading (?) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-06 03:14 +0000
                Re: best approach for multithreading (?) scott@slp53.sl.home (Scott Lurndal) - 2024-12-06 16:10 +0000
                Re: best approach for multithreading (?) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-06 18:20 +0000
                Re: best approach for multithreading (?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-12-07 00:16 -0500
                Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-06 22:37 -0800
                Re: best approach for multithreading (?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-07 06:10 -0800
                Re: best approach for multithreading (?) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-08 03:49 +0000
                Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-07 20:36 -0800
                Re: best approach for multithreading (?) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-08 09:31 +0000
                Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-08 15:12 -0800
                Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-08 15:18 -0800
                Re: best approach for multithreading (?) antispam@fricas.org (Waldek Hebisch) - 2024-12-09 00:39 +0000
              Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-06 12:14 -0800
    Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-01 14:59 -0800
  Re: best approach for multithreading (?) Bonita Montero <Bonita.Montero@gmail.com> - 2024-12-02 20:34 +0100
    Re: best approach for multithreading (?) fir <profesor.fir@gmail.com> - 2024-12-03 15:33 +0100

csiph-web