Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: "Naveen K. Kaushik" <naveenkumarkaushik@gmail.com>
Newsgroups: comp.programming.threads
Subject: Re: Locks for rarely changed data
Date: Tue, 09 Aug 2011 11:05:20 +0530
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <4E40C718.9010407@gmail.com>
References: <2716c873-a080-407a-88e8-a52904372920@h21g2000pre.googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: mx04.eternal-september.org; posting-host="Jr+GCtWa+XbvmSdRpa1MLQ"; logging-data="21445"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/lM6QTEkDPYB+yXf3j0S4bsygSGlbXqknsgQPwA+8+Kg=="
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
In-Reply-To: <2716c873-a080-407a-88e8-a52904372920@h21g2000pre.googlegroups.com>
Cancel-Lock: sha1:STi81qxEDgn+32UhU/7DpCx34G0=
Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:496

On 05-08-2011 PM 03:10, itt ium wrote:
> Group,
>
> I have a multithreaded software, that uses large amount of
> configuration data that is rarely modified (on the average  once in
> 2-3 days). This data is kept in the form of STL map, hash map etc
> which are not thread safe. Although data is rarely changed, we have to
> still protect it. Profiling data showed, good amount of CPU cycles
> used in locking/unlocking.
>
> I was thinking of giving separate copy of data to all the threads. A
> configuration chnage event will be delivered to each thread and thread
> then can read the new/modified configuration. In this way mutex will
> not be needed.
>
> Is there any other model of handling such a data without any locks.
>
> Because of the relevance I am posting the message to following groups.
>
>
> thanks
> Ittium

Theoretically, If data is rarely changed you can use reader/writer lock, 
practically it may not be a good idea, since reader/writer lock may not 
be less expensive than mutex and you can justify their usage only if 
readers are holding the data for large amount of time.

In one of our project, we were keeping the configuration data in the 
non-volatile memory, to read the data we will send the signal to the 
process. Signal handler will set the flag, in that case different 
threads will update their configuration data by reading from NV memory.
Thread will have their own copy of configuration data as suggested. 
Using this technique, you can avoid the locks.

Naveen