Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #389242 > unrolled thread

best approach for multithreading (?)

Back to article view | Back to comp.lang.c

Contents

  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

Page 1 of 2  [1] 2  Next page →

#389242 — best approach for multithreading (?)

[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

[toc] | [next] | [standalone]

#389259

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

[toc] | [prev] | [next] | [standalone]

#389263

On Sun, 01 Dec 2024 15:10:03 +0000, candycanearter07 wrote:

> 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)
[snip]
>>
>> 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).


-- 
Lew Pitcher
"In Skills We Trust"

[toc] | [prev] | [next] | [standalone]

#389265

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.

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.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#389275

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/


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

[toc] | [prev] | [next] | [standalone]

#389319

On 2024-12-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> 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/

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.


-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#389325

On 12/3/2024 9:48 AM, Kaz Kylheku wrote:
> On 2024-12-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> 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/
> 
> 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.


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

[toc] | [prev] | [next] | [standalone]

#389433

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.

[toc] | [prev] | [next] | [standalone]

#389440

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

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#389444

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.

[toc] | [prev] | [next] | [standalone]

#389450

On 2024-12-06, Scott Lurndal <scott@slp53.sl.home> wrote:
> 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.

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.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#389466

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?

[toc] | [prev] | [next] | [standalone]

#389467

On 12/6/2024 9:16 PM, James Kuyper 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?
> 

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

[toc] | [prev] | [next] | [standalone]

#389475

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

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

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

[toc] | [prev] | [next] | [standalone]

#389512

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.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#389514

On 12/7/2024 7:49 PM, Kaz Kylheku wrote:
> 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.
> 

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?

[toc] | [prev] | [next] | [standalone]

#389515

On 2024-12-08, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> 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?

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.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#389521

On 12/8/2024 1:31 AM, Kaz Kylheku wrote:
> On 2024-12-08, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> 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?
> 
> 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. :^)

[toc] | [prev] | [next] | [standalone]

#389522

On 12/8/2024 1:31 AM, Kaz Kylheku wrote:
> On 2024-12-08, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> 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?
> 
> 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?

[toc] | [prev] | [next] | [standalone]

#389523

Kaz Kylheku <643-408-1753@kylheku.com> wrote:
> 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.

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. 

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web