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

Groups > comp.lang.c++ > #85581 > unrolled thread

Multithreaded Programming : Always use spinlocks for performance?

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

Contents

  Multithreaded Programming : Always use spinlocks for performance? Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-07-24 06:31 -0700
    Re: Multithreaded Programming : Always use spinlocks for performance? Bo Persson <bo@bo-persson.se> - 2022-07-24 15:53 +0200
    Re: Multithreaded Programming : Always use spinlocks for performance? Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-24 16:42 +0200
    Re: Multithreaded Programming : Always use spinlocks for performance? Paavo Helde <eesnimi@osa.pri.ee> - 2022-07-24 18:09 +0300
      Re: Multithreaded Programming : Always use spinlocks for performance? Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-24 17:41 +0200
        Re: Multithreaded Programming : Always use spinlocks for performance? Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-07-24 09:20 -0700
          Re: Multithreaded Programming : Always use spinlocks for performance? Paavo Helde <eesnimi@osa.pri.ee> - 2022-07-24 19:34 +0300
          Re: Multithreaded Programming : Always use spinlocks for performance? Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-24 18:57 +0200
          Re: Multithreaded Programming : Always use spinlocks for performance? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-24 11:38 -0700
          Re: Multithreaded Programming : Always use spinlocks for performance? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-24 13:17 -0700
            Re: Multithreaded Programming : Always use spinlocks for performance? Öö Tiib <ootiib@hot.ee> - 2022-07-25 03:21 -0700
        Re: Multithreaded Programming : Always use spinlocks for performance? Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-24 19:01 +0200
    Re: Multithreaded Programming : Always use spinlocks for performance? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-24 13:20 -0700
      Re: Multithreaded Programming : Always use spinlocks for performance? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-24 16:55 -0700

#85581 — Multithreaded Programming : Always use spinlocks for performance?

I would post this post to a more generic group like "comp.programming.threads" however it's overrun with spam.

Earlier this week I posted on "comp.lang.c++" about a class I'd written to get a main thread and 8 worker threads to cooperate with each other.

I've been doing some testing, and I've tested it 3 ways:
(1) Using spinlocks
(2) Using one semaphore, one mutex and one condition_variable
(3) Using two semaphores per worker thread (i.e. 16 semaphores)

The slowest is No. 2. I haven't identified the exact reason why yet, but it's about 30 times slower than the other two ways.

No. 3 is quite good, but not the best.

No. 1 is the fastest. Is this to be expected? Is the only drawback of using spinlocks that they hog the CPU and so the operating system will be a big laggy?

So if you don't mind the CPU fan getting a bit load and the OS getting a big laggy, are you best to use spinlocks in your multi-threaded programs?

[toc] | [next] | [standalone]

#85582

On 2022-07-24 at 15:31, Frederick Virchanza Gotham wrote:
> 
> I would post this post to a more generic group like "comp.programming.threads" however it's overrun with spam.
> 
> Earlier this week I posted on "comp.lang.c++" about a class I'd written to get a main thread and 8 worker threads to cooperate with each other.
> 
> I've been doing some testing, and I've tested it 3 ways:
> (1) Using spinlocks
> (2) Using one semaphore, one mutex and one condition_variable
> (3) Using two semaphores per worker thread (i.e. 16 semaphores)
> 
> The slowest is No. 2. I haven't identified the exact reason why yet, but it's about 30 times slower than the other two ways.
> 
> No. 3 is quite good, but not the best.
> 
> No. 1 is the fastest. Is this to be expected? Is the only drawback of using spinlocks that they hog the CPU and so the operating system will be a big laggy?
> 
> So if you don't mind the CPU fan getting a bit load and the OS getting a big laggy, are you best to use spinlocks in your multi-threaded programs?
> 

A spinlock can be good if it is almost always free. It is low cost to 
just test it, and continue without spinning.

A spinlock is really bad if there is a 100 threads spinning on it.


As most of the time with software, there is no simple rule that always 
works. Rather usually "it depends".

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

#85583

Am 24.07.2022 um 15:31 schrieb Frederick Virchanza Gotham:
> 
> I would post this post to a more generic group like "comp.programming.threads" however it's overrun with spam.
> 
> Earlier this week I posted on "comp.lang.c++" about a class I'd written to get a main thread and 8 worker threads to cooperate with each other.
> 
> I've been doing some testing, and I've tested it 3 ways:
> (1) Using spinlocks
> (2) Using one semaphore, one mutex and one condition_variable
> (3) Using two semaphores per worker thread (i.e. 16 semaphores)
> 
> The slowest is No. 2. I haven't identified the exact reason why yet, but it's about 30 times slower than the other two ways.
> 
> No. 3 is quite good, but not the best.
> 
> No. 1 is the fastest. Is this to be expected? Is the only drawback of using spinlocks that they hog the CPU and so the operating system will be a big laggy?
> 
> So if you don't mind the CPU fan getting a bit load and the OS getting a big laggy, are you best to use spinlocks in your multi-threaded programs?
> 

Pure Spinlocks without any long path over the kernel doesn't
make sense in userland as a thread holding the mutex can be
scheduled away.
Spinning for a mutex a limited number of times can make sense
in rare cases. That's when the mutex has a extremely high lock-
ling-frequency and the mutex is held only a very short time
that spinning results in noteworthy more short paths. Otherwise
spinning for a mutex is below the measurement-error.

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

#85584

24.07.2022 16:31 Frederick Virchanza Gotham kirjutas:
> 
> I would post this post to a more generic group like "comp.programming.threads" however it's overrun with spam.
> 
> Earlier this week I posted on "comp.lang.c++" about a class I'd written to get a main thread and 8 worker threads to cooperate with each other.
> 
> I've been doing some testing, and I've tested it 3 ways:
> (1) Using spinlocks
> (2) Using one semaphore, one mutex and one condition_variable
> (3) Using two semaphores per worker thread (i.e. 16 semaphores)
> 
> The slowest is No. 2. I haven't identified the exact reason why yet, but it's about 30 times slower than the other two ways.
> 
> No. 3 is quite good, but not the best.
> 
> No. 1 is the fastest. Is this to be expected? Is the only drawback of using spinlocks that they hog the CPU and so the operating system will be a big laggy?
> 
> So if you don't mind the CPU fan getting a bit load and the OS getting a big laggy, are you best to use spinlocks in your multi-threaded programs?

It depends on what your goals are. If your goal is to get your program 
absolutely as fast as possible, and you have full control over your 
hardware and software, then spinlocks might be the solution. This is 
assuming you know exactly what you are doing (but in that case you would 
not need help from strangers in internet).

We lesser mortals need to write software for real world scenarios where 
there are other software pieces the customer wants to run on their 
computer, and sometimes they even have audacity to think our software 
piece is not the most important one. Getting the spinlocks wrong and 
blocking the whole machine needlessly is something which may easily 
happen, so I would not consider them unless the profiler says the 
standard mutex is becoming a bottleneck. This has never happened so far 
to me.

Also, before micro-optimizing the things like locking speed, one should 
review the algorithm. I have not found willingness to delve into your 
original post, but I see there is a regular  mandatory wait in all 
faster threads for the slowest one, plus the size of a single task 
seemed ridiculously small (8 kB). Even if those impediments are 
justified, it would be a pretty special scenario and one would not be 
able to draw many general conclusions about multithreading performance 
from that scenario.

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

#85585

Am 24.07.2022 um 17:09 schrieb Paavo Helde:

> It depends on what your goals are. If your goal is to get your program 
> absolutely as fast as possible, and you have full control over your 
> hardware and software, then spinlocks might be the solution. This is 
> assuming you know exactly what you are doing (but in that case you would 
> not need help from strangers in internet).

Spin-Locks are Locks with unlimted spinning, and this doesn't make
sense in userspace since the thread holding the lock can't disable
the scheduler so that it can't be scheduled away. This is necessary
because a thread spinning for a lock where the holder is scheduled
away can take extemely long.
Under Windows there are two types of spinlocks in kernel-space. One
type disables the scheduler only while holding the lock, the other
type is the so called interrupt spinlock, where the interrupt-level
on that core is raised to a specified level that a thread can compete
for resources with an interrupt, thereby disabling the interrupt.

So forget about using spinlocks in userspace !

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

#85586

On Sunday, July 24, 2022 at 4:40:54 PM UTC+1, Bonita Montero wrote:
>
> Spin-Locks are Locks with unlimted spinning <snip>


I need to clarify something here. I'm not sure if we're using the same terminology. When I say 'spin lock', what I mean is just checking an atomic variable in a loop. Something like as follows:

atomic<bool> g_should_process_data = false;

void Entry_Point_For_Worker_Thread(void)
{
        for (;;)
        {
                while ( false == g_should_process_data );    // <-- This is what I mean when I say 'spin lock'

                /* Process data */
        }
}

int main(void)
{
        thread t(Entry_Point_For_Worker_Thread);

        for (;;)
        {
                g_should_process_data = true;

                /* Do some other stuff */
        }
}

I'm not sure if you mean something else by "spin lock".

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

#85587

24.07.2022 19:20 Frederick Virchanza Gotham kirjutas:
> On Sunday, July 24, 2022 at 4:40:54 PM UTC+1, Bonita Montero wrote:
>>
>> Spin-Locks are Locks with unlimted spinning <snip>
> 
> 
> I need to clarify something here. I'm not sure if we're using the same terminology. When I say 'spin lock', what I mean is just checking an atomic variable in a loop. 

That would be a user-space spinlock which Bonita is talking about.

> 
> I'm not sure if you mean something else by "spin lock".

I was assuming you are using something like pthread_spin_lock() 
(https://man7.org/linux/man-pages/man3/pthread_spin_lock.3.html).

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

#85588

Am 24.07.2022 um 18:20 schrieb Frederick Virchanza Gotham:
> On Sunday, July 24, 2022 at 4:40:54 PM UTC+1, Bonita Montero wrote:
>>
>> Spin-Locks are Locks with unlimted spinning <snip>
> 
> 
> I need to clarify something here. I'm not sure if we're using the same terminology. When I say 'spin lock', what I mean is just checking an atomic variable in a loop. Something like as follows:

https://stackoverflow.com/questions/14723924/using-spinlocks-in-user-space-application

> atomic<bool> g_should_process_data = false;
> 
> void Entry_Point_For_Worker_Thread(void)
> {
>          for (;;)
>          {
>                  while ( false == g_should_process_data );    // <-- This is what I mean when I say 'spin lock'
> 
>                  /* Process data */
>          }
> }
> 
> int main(void)
> {
>          thread t(Entry_Point_For_Worker_Thread);
> 
>          for (;;)
>          {
>                  g_should_process_data = true;
> 
>                  /* Do some other stuff */
>          }
> }
> 
> I'm not sure if you mean something else by "spin lock".

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

#85591

Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> writes:
[...]
> void Entry_Point_For_Worker_Thread(void)
> {
>         for (;;)
>         {
>                 while ( false == g_should_process_data );    // <-- This is what I mean when I say 'spin lock'
>
>                 /* Process data */
>         }
> }
[...]

Not relevant to your question, but why would you write
`false == g_should_process_data` rather than `! should_process_data`?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#85594

On 7/24/2022 9:20 AM, Frederick Virchanza Gotham wrote:
> On Sunday, July 24, 2022 at 4:40:54 PM UTC+1, Bonita Montero wrote:
>>
>> Spin-Locks are Locks with unlimted spinning <snip>
> 
> 
> I need to clarify something here. I'm not sure if we're using the same terminology. When I say 'spin lock', what I mean is just checking an atomic variable in a loop. Something like as follows:
> 
> atomic<bool> g_should_process_data = false;
> 
> void Entry_Point_For_Worker_Thread(void)
> {
>          for (;;)
>          {
>                  while ( false == g_should_process_data );    // <-- This is what I mean when I say 'spin lock'
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Yikes! You really should have a backoff in there. Do you want your 
worker threads to be running full speed with absolutely nothing to do?


> 
>                  /* Process data */
>          }
> }
> 
> int main(void)
> {
>          thread t(Entry_Point_For_Worker_Thread);
> 
>          for (;;)
>          {
>                  g_should_process_data = true;
> 
>                  /* Do some other stuff */
>          }
> }
> 
> I'm not sure if you mean something else by "spin lock".

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

#85606

On Sunday, 24 July 2022 at 23:17:44 UTC+3, Chris M. Thomasson wrote:
> On 7/24/2022 9:20 AM, Frederick Virchanza Gotham wrote: 
> > On Sunday, July 24, 2022 at 4:40:54 PM UTC+1, Bonita Montero wrote: 
> >> 
> >> Spin-Locks are Locks with unlimted spinning <snip> 
> > 
> > 
> > I need to clarify something here. I'm not sure if we're using the same terminology. When I say 'spin lock', what I mean is just checking an atomic variable in a loop. Something like as follows: 
> > 
> > atomic<bool> g_should_process_data = false; 
> > 
> > void Entry_Point_For_Worker_Thread(void) 
> > { 
> > for (;;) 
> > { 
> > while ( false == g_should_process_data ); // <-- This is what I mean when I say 'spin lock'
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> 
> Yikes! You really should have a backoff in there. Do you want your 
> worker threads to be running full speed with absolutely nothing to do?

Yes. Whatever spinlock should be held for rather short time.  Here we are
misnaming infinitely busy poll loop (that is terrible anti-pattern) as
"spinlock". 

The symptoms  from OP that  "CPU fan getting a bit load and the OS
getting a big laggy" are because one of cores is full busy warming room.
It is visible in whatever activity monitor or task manager of operating
system and anyone half-savvy suggests to kill and uninstall it right away.

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

#85589

Am 24.07.2022 um 17:41 schrieb Bonita Montero:
> Am 24.07.2022 um 17:09 schrieb Paavo Helde:
> 
>> It depends on what your goals are. If your goal is to get your program 
>> absolutely as fast as possible, and you have full control over your 
>> hardware and software, then spinlocks might be the solution. This is 
>> assuming you know exactly what you are doing (but in that case you 
>> would not need help from strangers in internet).
> 
> Spin-Locks are Locks with unlimted spinning, and this doesn't make
> sense in userspace since the thread holding the lock can't disable
> the scheduler so that it can't be scheduled away. This is necessary
> because a thread spinning for a lock where the holder is scheduled
> away can take extemely long.
> Under Windows there are two types of spinlocks in kernel-space. One
> type disables the scheduler only while holding the lock, the other
> type is the so called interrupt spinlock, where the interrupt-level
> on that core is raised to a specified level that a thread can compete
> for resources with an interrupt, thereby disabling the interrupt.
> 
> So forget about using spinlocks in userspace !
> 

I forget to mention: really enjoying to have such discussions here
without Pete Olcott in the rhread. He is still dealing with the more
important issues. ;-)

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

#85595

On 7/24/2022 6:31 AM, Frederick Virchanza Gotham wrote:
> 
> I would post this post to a more generic group like "comp.programming.threads" however it's overrun with spam.
> 
> Earlier this week I posted on "comp.lang.c++" about a class I'd written to get a main thread and 8 worker threads to cooperate with each other.
> 
> I've been doing some testing, and I've tested it 3 ways:
> (1) Using spinlocks
> (2) Using one semaphore, one mutex and one condition_variable
> (3) Using two semaphores per worker thread (i.e. 16 semaphores)
> 
> The slowest is No. 2. I haven't identified the exact reason why yet, but it's about 30 times slower than the other two ways.
> 
> No. 3 is quite good, but not the best.
> 
> No. 1 is the fastest. Is this to be expected? Is the only drawback of using spinlocks that they hog the CPU and so the operating system will be a big laggy?
> 
> So if you don't mind the CPU fan getting a bit load and the OS getting a big laggy, are you best to use spinlocks in your multi-threaded programs?
> 

A main thread with multiple worker threads sounds like a great place for 
a single-producer/multi-consumer queue. If you are interested in sheer 
performance, there are several interesting options. Perhaps I can help 
you. Do you care if you get FIFO, or LIFO?

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

#85599

On 7/24/2022 1:20 PM, Chris M. Thomasson wrote:
> On 7/24/2022 6:31 AM, Frederick Virchanza Gotham wrote:
>>
>> I would post this post to a more generic group like 
>> "comp.programming.threads" however it's overrun with spam.
>>
>> Earlier this week I posted on "comp.lang.c++" about a class I'd 
>> written to get a main thread and 8 worker threads to cooperate with 
>> each other.
>>
>> I've been doing some testing, and I've tested it 3 ways:
>> (1) Using spinlocks
>> (2) Using one semaphore, one mutex and one condition_variable
>> (3) Using two semaphores per worker thread (i.e. 16 semaphores)
>>
>> The slowest is No. 2. I haven't identified the exact reason why yet, 
>> but it's about 30 times slower than the other two ways.
>>
>> No. 3 is quite good, but not the best.
>>
>> No. 1 is the fastest. Is this to be expected? Is the only drawback of 
>> using spinlocks that they hog the CPU and so the operating system will 
>> be a big laggy?
>>
>> So if you don't mind the CPU fan getting a bit load and the OS getting 
>> a big laggy, are you best to use spinlocks in your multi-threaded 
>> programs?
>>
> 
> A main thread with multiple worker threads sounds like a great place for 
> a single-producer/multi-consumer queue. If you are interested in sheer 
> performance, there are several interesting options. Perhaps I can help 
> you. Do you care if you get FIFO, or LIFO?

Oh. Reading your original thread.

[toc] | [prev] | [standalone]

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

csiph-web