943,155 Members | Top Members by Rank

Ad:
  • C++ Discussion Thread
  • Marked Solved
  • Views: 1322
  • C++ RSS
Feb 19th, 2010
0

STL map and thread safety

Expand Post »
In my application, i currently make many (parallel) calculations based on a time parameter. The calculation is a parametric function of time, so, each time value renders a unique solution. Currently, I have many threads that are calling the same calculation function, and the time parameters are often the same. The calculations can take some considerable amount of time.

I want to optimize by adding a hash-table like structure. So, instead of calculating and recalculating for identical times across many threads, I would prefer storing the calculation results in a hash-table keyed by the time. My application currently uses the STL for its containers, so I would like to use the map container.

Now, I know this container is not thread safe, so I am trying to devise a system to wrap the map object to ensure thread safety. I am considering two alternative methods to achieve this. Here is the (untested, uncompiled, just conceptual so far) code for the two methods:
C++ Syntax (Toggle Plain Text)
  1. double method0( double t, double (*calculate)(double) ){
  2. double result;
  3. omp_set_lock( &mapLock );
  4. if( calcMap.count(t) == 0 ){
  5. result = calculate(t);
  6. calcMap.insert( pair<double,double>( t, result ) );
  7. }
  8. else
  9. result = calcMap[t];
  10. omp_unset_lock( &mapLock );
  11. return result;
  12. }
  13.  
  14. double method1( double t, double (*calculate)(double) ){
  15. double result;
  16. if( calcMap.count(t) == 0 ){
  17. omp_set_lock( &mapLock );
  18. if( calcMap.count(t) == 0 )
  19. calcMap.insert( pair<double,double>( t, calculate(t) ) );
  20. omp_unset_lock( &mapLock );
  21. }
  22. return calcMap[t];
  23. }

Now, I think the first method should always work, because all access to the map is guarded by a lock. This is not preferable, though, because it introduces a huge serial bottle-neck that might not be necessary. Parallel reads shouldn't block each other. Also, there should be no reason that the map can't fetch calculations for times 0, 1, 2, and 3 if only 4 is being calculated and then inserted.

The second method would work, but only if the map adds an element as its last step of insert. Namely, as long as the element is allocated and set before it is added to the map, this method should be thread safe.

Does anyone know if I can make any assumptions about thread safety in the std::map class? If not, do you know of a method that is thread-safe and would perform better than my first method?

Thanks
Similar Threads
Reputation Points: 152
Solved Threads: 41
Posting Whiz in Training
dusktreader is offline Offline
255 posts
since Jan 2010
Feb 23rd, 2010
0
Re: STL map and thread safety
I have decided that instead of doing these calculations on the fly, I will do a pre-processing step first that will do all my calculations for all objects at all time positions. This should relieve any need for thread-safety in these maps.
Reputation Points: 152
Solved Threads: 41
Posting Whiz in Training
dusktreader is offline Offline
255 posts
since Jan 2010

This thread is solved

Either the thread starter or a moderator has marked this thread as solved. You can most likely trust the responses and answers given. There is most likely no reason for any further responses to be posted here. If you have a related question, please start a new thread in this forum instead.

This thread is more than three months old

No one has posted to this discussion for at least three months. Please let old threads die and do not reply to them unless you feel you have something new and valuable to contribute that absolutely must be added to make the discussion complete. Otherwise, please start a new thread in this forum instead.
Message:
Previous Thread in C++ Forum Timeline: Dummy head linked list
Next Thread in C++ Forum Timeline: help with encryption?





About Us | Contact Us | Advertise | Acceptable Use Policy
Forum Index | Build Custom RSS Feed


Follow us on Twitter


© 2011 DaniWeb® LLC