[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
fir <profesor.fir@gmail.com> wrote at 22:04 this Saturday (GMT):[snip]
[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)
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
On Sun, 01 Dec 2024 15:10:03 +0000, candycanearter07 wrote:
There's a standard library for multithreading.
https://www.man7.org/linux/man-pages/man7/pthreads.7.html
Since C11, the C standard library has provided it's own support for threading, which (I'm told) closely resembles the POSIX threading
model implemented in the Linux pthreads library.
On 12/1/2024 7:54 AM, Kaz Kylheku wrote:
On 2024-12-01, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
On Sun, 01 Dec 2024 15:10:03 +0000, candycanearter07 wrote:
There's a standard library for multithreading.
https://www.man7.org/linux/man-pages/man7/pthreads.7.html
Since C11, the C standard library has provided it's own support for
threading, which (I'm told) closely resembles the POSIX threading
model implemented in the Linux pthreads library.
Yes; they stupidly took a chunk of POSIX (IEE 1003 standard, originally
formed as a fork of C to standarize Unix things) and cloned an
incompatible version with different types and function names.
For over a decade before that, people were already using POSIX threads
on platforms that don't have POSIX threads, via libraries.
Here is one I used to always use back in the day over on Windows:
https://sourceware.org/pthreads-win32/
Think about it. The POSIX standard includes ISO C by reference.
So that means POSIX has to have two thread libraries.
It's a waste of flash in embedded systems.
On 12/3/24 12:48, Kaz Kylheku wrote:
...
Think about it. The POSIX standard includes ISO C by reference.
So that means POSIX has to have two thread libraries.
It's a waste of flash in embedded systems.
C <threads.h> can be implemented as a thin wrapper over POSIX threads.
The waste is relatively negligible. The differences, were intended to
allow <threads.h> to also be implemented on non-POSIX systems as
wrappers for whatever the native threading system was.
On 2024-12-06, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 12/3/24 12:48, Kaz Kylheku wrote:
...
Think about it. The POSIX standard includes ISO C by reference.
So that means POSIX has to have two thread libraries.
It's a waste of flash in embedded systems.
C <threads.h> can be implemented as a thin wrapper over POSIX threads.
The waste is relatively negligible. The differences, were intended to
allow <threads.h> to also be implemented on non-POSIX systems as
wrappers for whatever the native threading system was.
Generally speaking, you can have a function called pthread_create on >non-POSIX systems, and a header <pthread.h>.
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2024-12-06, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 12/3/24 12:48, Kaz Kylheku wrote:
...
Think about it. The POSIX standard includes ISO C by reference.
So that means POSIX has to have two thread libraries.
It's a waste of flash in embedded systems.
C <threads.h> can be implemented as a thin wrapper over POSIX threads.
The waste is relatively negligible. The differences, were intended to
allow <threads.h> to also be implemented on non-POSIX systems as
wrappers for whatever the native threading system was.
Generally speaking, you can have a function called pthread_create on >>non-POSIX systems, and a header <pthread.h>.
There are certain requirements of a posix threads implementation that
might be impossible for a non-POSIX system to implement efficiently;
windows, for example, doesn't support signals.
Kaz Kylheku <643-408-1753@kylheku.com> writes:...
On 2024-12-06, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
C <threads.h> can be implemented as a thin wrapper over POSIX threads.
The waste is relatively negligible. The differences, were intended to
allow <threads.h> to also be implemented on non-POSIX systems as
wrappers for whatever the native threading system was.
Generally speaking, you can have a function called pthread_create on
non-POSIX systems, and a header <pthread.h>.
There are certain requirements of a posix threads implementation that
might be impossible for a non-POSIX system to implement efficiently;
windows, for example, doesn't support signals.
My words above not-withstanding, [...]
On 12/6/24 11:10, Scott Lurndal wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:...
On 2024-12-06, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
C <threads.h> can be implemented as a thin wrapper over POSIX threads. >>>> The waste is relatively negligible. The differences, were intended to
allow <threads.h> to also be implemented on non-POSIX systems as
wrappers for whatever the native threading system was.
Generally speaking, you can have a function called pthread_create on
non-POSIX systems, and a header <pthread.h>.
There are certain requirements of a posix threads implementation that
might be impossible for a non-POSIX system to implement efficiently;
windows, for example, doesn't support signals.
My words above not-withstanding, I am not in any sense an expert on any
kind of threading, nor of Windows. What does POSIX require of threads
with regards to signals?
On 12/7/2024 7:49 PM, Kaz Kylheku wrote:
On 2024-12-07, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
My words above not-withstanding, I am not in any sense an expert on any
kind of threading, nor of Windows. What does POSIX require of threads
with regards to signals?
Off the top of my head, the highlights:
- threads have their own signal masks, inherited from the creator which
calls pthtead_create.
- signal masks can be manipulated so that a given signal will be
handled in the context of a desired thread.
- sigwait (and several other functions) can be used by a thread to
wait for one or more signals, allowing signals to be process
synchronously, somewhat like message passing.
Semaphores are sig safe, so to speak. It's been a while:
https://www.man7.org/linux/man-pages/man3/sem_post.3.html
should be sig safe? Or, am I wrong here Kaz?
On 2024-12-07, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 12/6/24 11:10, Scott Lurndal wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:...
On 2024-12-06, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
C <threads.h> can be implemented as a thin wrapper over POSIX threads. >>>>> The waste is relatively negligible. The differences, were intended to >>>>> allow <threads.h> to also be implemented on non-POSIX systems as
wrappers for whatever the native threading system was.
Generally speaking, you can have a function called pthread_create on
non-POSIX systems, and a header <pthread.h>.
There are certain requirements of a posix threads implementation that
might be impossible for a non-POSIX system to implement efficiently;
windows, for example, doesn't support signals.
My words above not-withstanding, I am not in any sense an expert on any
kind of threading, nor of Windows. What does POSIX require of threads
with regards to signals?
Off the top of my head, the highlights:
- threads have their own signal masks, inherited from the creator which
calls pthtead_create.
- signal masks can be manipulated so that a given signal will be
handled in the context of a desired thread.
- sigwait (and several other functions) can be used by a thread to
wait for one or more signals, allowing signals to be process
synchronously, somewhat like message passing.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 164:59:40 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,518 |