Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #3810 > unrolled thread
| Started by | aminer <aminer@toto.net> |
|---|---|
| First post | 2013-09-30 12:13 -0700 |
| Last post | 2013-09-30 12:20 -0700 |
| Articles | 3 — 1 participant |
Back to article view | Back to comp.programming
About my Scalable distributed Lock... aminer <aminer@toto.net> - 2013-09-30 12:13 -0700
Re: About my Scalable distributed Lock... aminer <aminer@toto.net> - 2013-09-30 12:17 -0700
Re: About my Scalable distributed Lock... aminer <aminer@toto.net> - 2013-09-30 12:20 -0700
| From | aminer <aminer@toto.net> |
|---|---|
| Date | 2013-09-30 12:13 -0700 |
| Subject | About my Scalable distributed Lock... |
| Message-ID | <l2c7vh$4ff$1@news.albasani.net> |
Hello, We have to be very carefull, i have benchmaked my Scalable distributed Lock version 1.1, and i have noticed that since it uses a Ticket mechanism it doesn't scale, the problem with the Ticket mechanism is that it has a poor performance cause in the case of a spinlock without tickets when it is unlocked() the first thread that comes first to the lock() will enter immediatly the locked section, but that's not the case with a Ticket spinlock cause if the first thread that enters the lock() first has not the ticket to enter, the other thread that have the ticket to enter and that is waiting for his turn will wait longer/more, if there is also context switches it will wait longer, so this is why the Ticket spinlock has a poor performance compared to a simple spinlock with a backoff, so i have decided to return back my scalable distributed Lock version 1.0, the version 1.0 doesn't use a ticket mechanism but it is much fair that the Windows critical section , other than that i have benchmarked the Windows critical section and i have noticed that it doesn't scale well , my scalable distributed Lock scales much better , also my scalable distributed Lock spins on local variable so it reduces the cache misses and it reduces the cache-coherence traffic, the Windows critical section spins on a local variable so it's less efficient than my scalable distributed Lock. Thank you, Amine Moulay Ramdane.
[toc] | [next] | [standalone]
| From | aminer <aminer@toto.net> |
|---|---|
| Date | 2013-09-30 12:17 -0700 |
| Message-ID | <l2c86g$4ff$4@news.albasani.net> |
| In reply to | #3810 |
Hello, You can download my scalable distributed Lock version 1.0 from: http://pages.videotron.com/aminer/ Thank you, Amine Moulay Ramdane. On 9/30/2013 12:13 PM, aminer wrote: > > Hello, > > > We have to be very carefull, i have benchmaked my Scalable distributed Lock > version 1.1, and i have noticed that since it uses a Ticket mechanism it > doesn't scale, the problem with the Ticket mechanism is that it has a > poor performance cause in the case of a spinlock without tickets when it > is unlocked() the first thread that comes first to the lock() will enter > immediatly the locked section, but that's not the case with a Ticket > spinlock cause if the first thread that enters the lock() first has not > the ticket to enter, the other thread that have the ticket to enter and > that is waiting for his turn will wait longer/more, if there is > also context switches it will wait longer, so this is why the Ticket > spinlock has a poor performance compared to a simple spinlock with a > backoff, so i have decided to return back my scalable distributed Lock > version 1.0, the version 1.0 doesn't use a ticket mechanism but it > is much fair that the Windows critical section , other than that > i have benchmarked the Windows critical section and i have noticed that > it doesn't scale well , my scalable distributed Lock scales much better > , also my scalable distributed Lock spins on local variable so it reduces > the cache misses and it reduces the cache-coherence traffic, the Windows > critical section spins on a local variable so it's less efficient than > my scalable distributed Lock. > > > > Thank you, > Amine Moulay Ramdane. > > > > > >
[toc] | [prev] | [next] | [standalone]
| From | aminer <aminer@toto.net> |
|---|---|
| Date | 2013-09-30 12:20 -0700 |
| Message-ID | <l2c8cj$5dq$1@news.albasani.net> |
| In reply to | #3810 |
I correct some typos , please read again... Hello, We have to be very carefull, i have benchmaked my Scalable distributed Lock version 1.1, and i have noticed that since it uses a Ticket mechanism it doesn't scale, the problem with the Ticket mechanism is that it has a poor performance cause in the case of a spinlock without tickets when it is unlocked() the first thread that comes first to the lock() will enter immediatly the locked section, but that's not the case with a Ticket spinlock cause if the first thread that enters the lock() first has not the ticket to enter, the other thread that have the ticket to enter and that is waiting for his turn will wait longer/more, if there is also context switches it will wait longer, so this is why the Ticket spinlock has a poor performance compared to a simple spinlock with a backoff, so i have decided to return back to my scalable distributed Lock version 1.0, the version 1.0 doesn't use a ticket mechanism but it is much fair that the Windows critical section , other than that i have benchmarked the Windows critical section and i have noticed that it doesn't scale well , my scalable distributed Lock scales much better , also my scalable distributed Lock spins on local variables so it reduces the cache misses and it reduces the cache-coherence traffic, the Windows critical section spins on a global variable so it's less efficient than my scalable distributed Lock. Thank you, Amine Moulay Ramdane.
[toc] | [prev] | [standalone]
Back to top | Article view | comp.programming
csiph-web