Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.pascal.misc > #954
| From | Ramine <ramine@1.1> |
|---|---|
| Newsgroups | comp.lang.pascal.misc |
| Subject | Lock convoy and my scalable MLock |
| Date | 2014-09-14 18:40 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <lv55fe$5c3$3@dont-email.me> (permalink) |
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 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 is working only in user space and this is good , cause it highers 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.
Back to comp.lang.pascal.misc | Previous | Next | Find similar
Lock convoy and my scalable MLock Ramine <ramine@1.1> - 2014-09-14 18:40 -0700
csiph-web