Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #487 > unrolled thread

Locks for rarely changed data

Back to article view | Back to comp.programming.threads

Contents

  Locks for rarely changed data itt ium <ittium@gmail.com> - 2011-08-05 02:40 -0700
    Re: Locks for rarely changed data "Naveen K. Kaushik" <naveenkumarkaushik@gmail.com> - 2011-08-09 11:05 +0530
    Re: Locks for rarely changed data Robert Wessel <robertwessel2@yahoo.com> - 2011-08-09 02:07 -0500
    Re: Locks for rarely changed data David Schwartz <davids@webmaster.com> - 2011-08-10 12:34 -0700
      Re: Locks for rarely changed data itt ium <ittium@gmail.com> - 2011-08-12 00:04 -0700

#487 — Locks for rarely changed data

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

[toc] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#497

On Fri, 5 Aug 2011 02:40:03 -0700 (PDT), itt ium <ittium@gmail.com>
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.



Rather than giving each thread a copy of the data, give each thread a
lightweight mutex.  Each thread only acquires its own mutex, that
should be very fast since there will never be contention (except
during an update), and it should always be in cache.  The writer,
OTOH, has to acquire *all* of the mutexes before proceeding with the
update (but that's very rare, by definition).  Obviously that requires
some way of tracking the active threads, but that requires work only
when threads are created and destroyed.


Alternatively, if you can keep two copies of the data, and you can
allow existing users to continue while the update occurs (and new
users start to use the new data), you can do the whole thing
lock-free.  You just need a (global) instance flag and a reference
count and active flag in each instance (all accesses to those would
need to be atomic).  You'd have something like:

reader_acquire:
  read global_instance_flag, select instance
  save selected instance for later
  atomic increment instance.refcount
  if not instance.active, decrement .refcount, repeat

reader_release:
  atomic decrement instance.refcount

writer:    
  (assumes single writer)
  read global_instance_flag, select *other* instance
  while instance.refcount !=0
    delay, loop
  load new data to instance
  set instance.active = true  
  flip global_instance_flag
  set old_instance.active = false

[toc] | [prev] | [next] | [standalone]

#501

On Aug 5, 2:40 am, itt ium <itt...@gmail.com> wrote:

> 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.

Another possibility is just to have each thread make its own copy.
This method is fast and efficient but doesn't guarantee that each
thread immediately sees any changes. (In practice, on all current
platforms, it will see them within a tiny fraction of a second).

To change the global data:

1) Acquire a global mutex.
2) Change the data.
3) Increment a global volatile integer.
4) Release the mutex.

To acquire the data:
1) Acquire the mutex.
2) Copy the global volatile integer.
3) Copy the data.
4) Release the mutex.

To use the data:
1) Compare the copy of the global volatile integer (from step '2'
above) with the current value. If they don't match, acquire the data
again.
2) Use the copy of the data from step '3' above.

Technically, this is platform-specific, but it works on every platform
I know of. If your platform has atomic operations, use them for the
integer instead of volatile and then the semantics are guaranteed.

DS

[toc] | [prev] | [next] | [standalone]

#507

On Aug 11, 12:34 am, David Schwartz <dav...@webmaster.com> wrote:
> On Aug 5, 2:40 am, itt ium <itt...@gmail.com> wrote:
>
> > 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.
>
> Another possibility is just to have each thread make its own copy.
> This method is fast and efficient but doesn't guarantee that each
> thread immediately sees any changes. (In practice, on all current
> platforms, it will see them within a tiny fraction of a second).
>
> To change the global data:
>
> 1) Acquire a global mutex.
> 2) Change the data.
> 3) Increment a global volatile integer.
> 4) Release the mutex.
>
> To acquire the data:
> 1) Acquire the mutex.
> 2) Copy the global volatile integer.
> 3) Copy the data.
> 4) Release the mutex.
>
> To use the data:
> 1) Compare the copy of the global volatile integer (from step '2'
> above) with the current value. If they don't match, acquire the data
> again.
> 2) Use the copy of the data from step '3' above.
>
> Technically, this is platform-specific, but it works on every platform
> I know of. If your platform has atomic operations, use them for the
> integer instead of volatile and then the semantics are guaranteed.
>
> DS

This is precisely what I was looking for. Thanks a lot DS

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web