Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!goblin2!goblin.stu.neva.ru!newsfeed2.atman.pl!newsfeed.atman.pl!.POSTED!not-for-mail From: Edek Newsgroups: comp.programming.threads Subject: Re: Mutex or reader writer lock Date: Thu, 23 Jun 2011 00:14:30 +0200 Organization: ATMAN - ATM S.A. Lines: 60 Message-ID: References: NNTP-Posting-Host: 83-238-152-145.ip.netia.com.pl Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: node2.news.atman.pl 1308780827 20238 83.238.152.145 (22 Jun 2011 22:13:47 GMT) X-Complaints-To: usenet@atman.pl NNTP-Posting-Date: Wed, 22 Jun 2011 22:13:47 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Linux/3.1.0-15 Thunderbird/3.1.0 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:355 On 06/21/2011 12:27 PM, ittium wrote: > Hi group, > I plan to use pthread read write lock for one of my products. I did > some research and found out that reader writer lock consume more CPU > than mutex. Folloiwng is my understanding, please comment on these > points > > 1. There are mostly read operations on the shared data and there are > **large** number of readers so even if there is cpu penalty of using > reader writer lock, multiple threads can simultaneously work with > rwlock That's the basic idea of an rwlock. I assume this post is not related to your nearby posts, where readers just fetch something under lock and work on it later outside. . > > 2. If there are mostly read operations but there are **not many > readers** than contention will be small and it is better to use mutex > since mutex locking/unlocking is light weight "Not many readers" is not enough information. a) comment above, b) contention depends not only on count, but also on time of operations and frequency, sometimes even patterns > > 3.If read operations are **heavy weight**, **irrespective of number of > readers**, It is always a good idea to use reader writer locks in > place of mutex since so even if there is cpu penalty of using reader > writer lock, multiple threads can simultaneously work > See above. In general the topic of lock granularity comes to (my) mind, a way to lower the contention. I mean, if there is a really "heavy weight" operation holding a lock all the time, something has to wait. Even under RWLock, you can imagine one reader thread blocking everything else for however long it runs. And, > **irrespective of number of >> readers** if there is one, there is no need for an rwlock, FWIW. > I will also appreciate, few lines on pthread reader writer locks > implementation. Is is using futex and condition variables ? > I don't know what platform you are referring to, but atomic + futex as far as I know (plus bookkeeping of course) > thanks > Ittium Edek