Konstantin: Roch Bourbonnais has a blog entry about some of the less obvious performance aspects of rwlocks:
http://blogs.sun.com/roch/entry/beware_of_the_performance_of It may have information that is useful to your particular situation. > most of the time rw lock is read locked by several threads. it worx as > expected in all setups except one. customer with 16 ultra IV cpus had > terrible performance problems with this daemon. investigation revealed > that half of threads spend 90% of time in read lock call. A writer waiting for access on a RWlock can impact the performance of subsequent readers, as they'll have to block too. Before you blame the OS or the CPU architecture, it would make sense to investigate whether there is something specific about the customer's use of this daemon that causes write-locks to be required on a more frequent basis than the other customers who report no issues with this particular daemon. If the problem really is in the daemon, you'll have better luck addressing the issue there, instead of trying to workaround the problem by using a different computer or OS. > using temporary binary wo read lock - problem solved. we have also Did you change the type of lock that was used, or just remove the lock completely? > is it expected behavior for sol9 that read RW lock being used by 10+ > threads simultaneously has very bad performance? I think this depends entirely upon how the lock is used. Is the source-code available for this daemon? -j _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
