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

Groups > comp.programming > #3790 > unrolled thread

About Spinlock...

Back to article view | Back to comp.programming

Contents

  About Spinlock... aminer <aminer@toto.net> - 2013-09-24 18:27 -0700
    Re: About Spinlock... aminer <aminer@toto.net> - 2013-09-24 18:58 -0700
    Re: About Spinlock... aminer <aminer@toto.net> - 2013-09-24 19:00 -0700

#3790 — About Spinlock...

Hello,

I think i have discovered what gone wrong with the following Spinlock
with a Dynamic Sleep:

http://code.google.com/p/gpdelphiunits/source/browse/trunk/src/SpinLock.pas?r=37 



First you will notice that they are using a Dynamic Sleep , not
an exponential backoff, and that's not correct, cause you have to use an 
exponential backoff to be able to lower correctly the contention,
second, if you have noticed  this Dynamic Sleep or the exponential
backoff do use the Sleep() function to lower the contention , but
this is not correct, cause when you use an exponential backoff with
the Sleep() when the CAS fails under contention it will sleep for 
milliseconds and that's too long and it will make you Spinlock very 
slow, so the correct solution is to use the PAUSE instruction instead of 
Sleep() like this:


for i:=0 to LSleepAmount do asm pause end;

and after that call also Sleep(0), to not freeze your computer.

I have patched the above Spinlock like that adding an exponential 
backoff that uses
the pause instruction instead of the Sleep() and the Spinlock
have worked perfectly even under contention.


So i think i will return now back to the Spinlock with Exponential backoff
cause it has a good performance.


Thank you,
Amine Moulay Ramdane.

[toc] | [next] | [standalone]

#3791

Hello,

Personnaly i love very much he Spinlock with an exponential cause it is
a simple and efficient and a bright idea, the exponential backoff will 
amortize/lower a lot the cache transfer between the cores this is why it 
has almost the
same performance as the MCS queue Lock (look to the graphs inside
the following link and you will be convinced). And  if you say
what about the starvation problem ? Look at the following, it says this:

"Starvation freedom is desirable, but not essential
—practical locks: many permit starvation, although it is unlikely to occur"

Read here:

http://www.cs.rice.edu/~vs3/comp422/lecture-notes/comp422-lec19-s08-v1.pdf

As you have noticed it says Starvation freedom is "not essential" , 
other than that with fair locks as the MCS queue Lock
we risk the problem of lock convoy this is why i love very much the 
Spinlock with
and Exponential backoff cause that was a simple and bright and efficient 
idea.




Thank you,
Amine Moulay Ramdane.

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

#3792

Hello,

Personaly i love very much the Spinlock with an exponential cause it is
a simple and efficient and a bright idea, the exponential backoff will 
amortize/lower a lot the cache transfer between the cores this is why it 
has almost the
same performance as the MCS queue Lock (look to the graphs inside
the following link and you will be convinced). And  if you say
what about the starvation problem ? Look at the following, it says this:

"Starvation freedom is desirable, but not essential
—practical locks: many permit starvation, although it is unlikely to occur"

Read here:

http://www.cs.rice.edu/~vs3/comp422/lecture-notes/comp422-lec19-s08-v1.pdf

As you have noticed it says Starvation freedom is "not essential" , 
other than that with fair locks as the MCS queue Lock
we risk the problem of lock convoy this is why i love very much the 
Spinlock with
and Exponential backoff cause that was a simple and bright and efficient 
idea.




Thank you,
Amine Moulay Ramdane.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web