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

Groups > comp.programming.threads > #2591 > unrolled thread

About lock convoy and my scalable MLock ....

Back to article view | Back to comp.programming.threads

Contents

  About lock convoy and my scalable MLock .... Ramine <ramine@1.1> - 2014-09-14 17:06 -0700
    Re: About lock convoy and my scalable MLock .... Ramine <ramine@1.1> - 2014-09-14 17:19 -0700

#2591 — About lock convoy and my scalable MLock ....

Hello,


As you have noticed i have implemented a scalable Lock better
than the MCS lock called scalable MLock, here it is:

https://sites.google.com/site/aminer68/scalable-mlock


But i have forgot to spook about Lock convoy, as you have noticed
the Optex lock implemented here by Jeffrey Richter have tries to avoid
Lock convoy in its second implementation cause context switch to the
kernel mode by the semaphore is expensive and this will make the
service rate of the critical section more expensive and this is not good..

Read here:

http://msdn.microsoft.com/en-us/magazine/cc163642.aspx


But in my scalable MLock i am not context switching to kernel mode cause 
my scalable MLock working only in user space and this is good , cause it 
lowers the service rate of the critical section and this is better to 
reduce the probability to have a Lock convoy, other than that
to reduce better the probability of lock convoy or to avoid completly
lock convoy the service rate of the critical section must be faster than 
the arrival rate of the threads to the critical section and
also you can lower the size of the critical section also.


So hope you will find my new algorithm called scalable MLock
very interresting.


Thank you,
Amine Moulay Ramdane.

[toc] | [next] | [standalone]

#2593

On 9/14/2014 5:06 PM, Ramine wrote:
> Hello,
>
>
> As you have noticed i have implemented a scalable Lock better
> than the MCS lock called scalable MLock, here it is:
>
> https://sites.google.com/site/aminer68/scalable-mlock
>
>
> But i have forgot to spook about Lock convoy, as you have noticed
> the Optex lock implemented here by Jeffrey Richter have tries to avoid
> Lock convoy in its second implementation cause context switch to the
> kernel mode by the semaphore is expensive and this will make the
> service rate of the critical section more expensive and this is not good..
>
> Read here:
>
> http://msdn.microsoft.com/en-us/magazine/cc163642.aspx
>
>
> But in my scalable MLock i am not context switching to kernel mode cause
> my scalable MLock working only in user space and this is good , cause it
> lowers the service rate of the critical section and this is better to


I mean it highers the service rate, not it lowers...


> reduce the probability to have a Lock convoy, other than that
> to reduce better the probability of lock convoy or to avoid completly
> lock convoy the service rate of the critical section must be faster than
> the arrival rate of the threads to the critical section and
> also you can lower the size of the critical section also.
>
>
> So hope you will find my new algorithm called scalable MLock
> very interresting.
>
>
> Thank you,
> Amine Moulay Ramdane.
>
>
>
>
>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web