849 Subj : Re: performance of single mutex versus Read/write mutex: any numbers? discuss To : comp.programming.threads From : Howard Hinnant Date : Tue Oct 11 2005 08:52 pm In article , Joe Seigh wrote: > Howard Hinnant wrote: > > > > This link might be helpful: > > > > http://home.twcny.rr.com/hinnant/cpp_extensions/rw_perf.html > > > > It contains demo test code which attempts to justify the use case for > > read/write and even read/write/upgradable locks. Timing results for a > > dual processor machine are presented. The link also describes a "lock > > reduced" mutex which avoids locking an OS-based mutex if there is no > > contention, although there is no code, just hand-waving. > > > > At best this paper should only convince you that perhaps it is worth the > > trouble to code it up both ways and measure. > > > > You're measuring whichever of the readers or writers takes longer. Plus > the difference between the two can be dramatic. For example, if all the > readers ran first real quick, what you end up measuring in effect is just > the writers. You're better off just running one, e.g. the writers, for > a fixed number of iterations, and running the other, the readers, as long > as there are writers running. And then report (write|reads)/sec/thread > instead of overall run time. The intended design was to starve neither readers nor writers. This goal was achieved on the target platform, but testing on other platforms wasn't performed. I wish I had some way to quantify and present the fairness that was achieved. By monitoring both the print statements and a cpu "activity monitor" I am confident of a high degree of fairness (all threads started and ended their tasks very close to one another relative to the length of those tasks). > Also, it would be nice to see a comparision with Posix rwlock. Just > comparing against Posix mutex is too much apples and oranges. Yes, that would be very interesting. I hope I get the time to do that. -Howard . 0