best approach for multithreading (?)

[fir]

[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

[candycanearter07]

Post by fir
[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

[Lew Pitcher]

Post by candycanearter07

Post by fir
[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)

[snip]

Post by candycanearter07

Post by fir
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

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.

Fir might check out the C standard first (as code written to that
standard will be portable to any environment that supports C11).

[Kaz Kylheku]

Post by Lew Pitcher

Post by candycanearter07
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.

That's an excellent solution that moves out of the way on platforms
where you do have POSIX threads.

Standards cribbing from other standards, and changing things, is totally
counterproductive.

[Chris M. Thomasson]

Post by Kaz Kylheku

Post by Lew Pitcher

Post by candycanearter07
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/

Post by Kaz Kylheku
That's an excellent solution that moves out of the way on platforms
where you do have POSIX threads.
Standards cribbing from other standards, and changing things, is totally
counterproductive.

[Kaz Kylheku]

Post by Chris M. Thomasson

Post by Kaz Kylheku

Post by Lew Pitcher

Post by candycanearter07
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.

https://sourceware.org/pthreads-win32/

And that is not significantly harder to implement (if at all) than C11
threading.

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.

[Chris M. Thomasson]

Post by Kaz Kylheku

Post by Chris M. Thomasson

Post by Kaz Kylheku

Post by Lew Pitcher

Post by candycanearter07
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.

https://sourceware.org/pthreads-win32/

And that is not significantly harder to implement (if at all) than C11
threading.

Back then, iirc, it was "hard", or "tricky" to create a compliant
condition variable on windows. There were a lot of tries, but 90% of
them had issues. Some of them only supported SCHED_OTHER, and others
would seem to work until they deadlocked. Missing waiter thing. God, its
been a while! Way back in very early 2000's for me.

Post by Kaz Kylheku
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.

POSIX needs a whole system to be compliant (compiler, ect...). I
remember an old post over on c.p.t where, iirc, GCC broke this contract
wrt a pthread_mutex_trylock(). I wonder if I can still find that damn
thread! I posted in it and so did Dave Butenhof.

[James Kuyper]

On 12/3/24 12:48, Kaz Kylheku wrote:
...

Post by Kaz Kylheku
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.

[Kaz Kylheku]

Post by James Kuyper
...

Post by Kaz Kylheku
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>.

[Scott Lurndal]

Post by Kaz Kylheku

Post by James Kuyper
...

Post by Kaz Kylheku
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]

Post by Scott Lurndal

Post by Kaz Kylheku

Post by James Kuyper
...

Post by Kaz Kylheku
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.

It's better to remove requirements from the POSIX standard to implement
a useful subset of POSIX threads, than to remove requirements from POSIX
threads and then change all the names to ISO C threads, to create a
redundant specification.

[James Kuyper]

...

Post by Scott Lurndal

Post by Kaz Kylheku

Post by James Kuyper
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?

[Chris M. Thomasson]

Post by James Kuyper
...

Post by Scott Lurndal

Post by Kaz Kylheku

Post by James Kuyper
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?

Well, think of a signal safe function vs one that is not.

[Tim Rentsch]

My words above not-withstanding, [...]

In English, notwithstanding is a single word, not a two-word
hyphenation, and has been for hundreds of years.

[Kaz Kylheku]

Post by James Kuyper
...

Post by Scott Lurndal

Post by Kaz Kylheku

Post by James Kuyper
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.

[Chris M. Thomasson]

Post by Kaz Kylheku

Post by James Kuyper
...

Post by Scott Lurndal

Post by Kaz Kylheku

Post by James Kuyper
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?

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

[Kaz Kylheku]

Post by Chris M. Thomasson

Post by Kaz Kylheku

Post by James Kuyper
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?

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

https://www.man7.org/linux/man-pages/man3/sem_post.3.html
should be sig safe? Or, am I wrong here Kaz?

Yes; just not sem_wait. The obvious idea there is that a signal handler
is like an interrupt service top half, and those must be able to bang
semaphores, to wake up something waiting in the bottom half code.

[Chris M. Thomasson]

Post by Kaz Kylheku

Post by Chris M. Thomasson

Post by Kaz Kylheku

Post by James Kuyper
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?

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

https://www.man7.org/linux/man-pages/man3/sem_post.3.html
should be sig safe? Or, am I wrong here Kaz?

Yes; just not sem_wait. The obvious idea there is that a signal handler
is like an interrupt service top half, and those must be able to bang
semaphores, to wake up something waiting in the bottom half code.

Exactly. Actually, I remember a while back (several decades ago) when I
was experimenting with lock/wait-free algorithms in sig handlers. They
worked fine. Some of the algorithms would allow one to conditionally
wait (futex, eventcount, ect...) say wait on a lock-free stack empty
condition. So those could not be used. However, the "try" versions of
them would work fine. :^)

[Chris M. Thomasson]

Post by Kaz Kylheku

Post by Chris M. Thomasson

Post by Kaz Kylheku

Post by James Kuyper
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?

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

https://www.man7.org/linux/man-pages/man3/sem_post.3.html
should be sig safe? Or, am I wrong here Kaz?

Yes; just not sem_wait. The obvious idea there is that a signal handler
is like an interrupt service top half, and those must be able to bang
semaphores, to wake up something waiting in the bottom half code.

sem_trywait?

[Waldek Hebisch]

Post by Kaz Kylheku

Post by James Kuyper
...

Post by Scott Lurndal

Post by Kaz Kylheku

Post by James Kuyper
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?

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

Hmm, as long as there is no way to generate signals the above
can be implemented as a no-op or close (say possibly storing
mask somewhere so that application can get it back). Of
course, it would be harder if Windows has signals or if
POSIX requires ability to generate signals.

[Chris M. Thomasson]

Post by James Kuyper
...

Post by Kaz Kylheku
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.

Actually that reminds me of an older little "thing" I did when I had
nothing to do:

https://groups.google.com/g/comp.lang.c/c/WPH7ed5uS4Y

;^)

[Chris M. Thomasson]

Post by candycanearter07

Post by fir
[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

What about C11? ;^)

[Bonita Montero]

That's how thread-pools work. In C++ you'd simply feed a deque<> of
function<>-objects to a limited number of threads. In C that's possible
similar but with ten lines the code.

[fir]

Post by Bonita Montero
That's how thread-pools work. In C++ you'd simply feed a deque<> of
function<>-objects to a limited number of threads. In C that's possible
similar but with ten lines the code.

i probably would need to see that but i guess probably there are some
differences

(here for exampe yu dont need to use a term 'thread' its like more
low lewel integrated)