On 9???13???, ??????9???59???, Jerry Coffin <jcof...@taeus.com> wrote:
In article <d7d947bf-a634-4b9b-9d51-
7541de1d1...@s1g2000pra.googlegroups.com>, billdavi...@gmail.com says...
SUBJECT: How to make this program more efficient?
In my program, a thread will check update from server periodically and
generate a stl::map for other part of this program to read data from.
Let's name the update method as doUpdate and stl::map read methods as
getData and copyData.
Since stl::map is not thread-safe, we should do synchronization by
ourselves. A usable solution is to create a boost::mutex::scoped_lock
object in all above methods to make the access to all methods
synchronized. But since the doUpdate method will be executed
periodically and the interval may be 1 hour or longer, while all other
parts can only read the stl::map, the above solution may do
synchronization too much. We only need synchronization on all methods
when we are doUpdating.
Then is it possible to make this program more efficient?
I have thought out some other solution like add some updating flag.
But it's not safe since stl::map may be updated when the following
part of read methods is executing. And the operation on the flag may
also be interrupted by other threads.
I'd collect the data into a separate map (or perhaps vector or whatever)
and only when you've collected all the data for a single update, copy it
all into the map. This way the map only needs to be locked for the
duration of the copy.
If this is still longer than you like, you can access the map via a
pointer. When you're going to do an update, you create a copy of the
map, update the copy, and then update the pointer to refer to the newly
updated copy of the map (then dispose of the old map). This way, you
only need a "lock" for the duration of one pointer update -- but most
architectures will support an atomic swap operation without needing any
other locks.
This, however, is one of the rare cases where using volatile is
necessary for thread safety -- the other threads need to treat the
pointer as volatile, so as soon as the pointer changes, they use the new
pointer value and refer only to the new map. If any of the other threads
"stores" the value of the pointer (at all, even just passing it as a
parameter) you'll need to synchronize access to the pointer, only
disposing of the old map after all other threads have signaled that
they're finished using it.
--
Later,
Jerry.
The universe is a figment of its own imagination.- ????????????????????? -
- ????????????????????? -
Sorry, I am still not so clear about what you mean. I am not sure if
it's a little like RCU algorithom mentioned by Jon Harrop. But as I
know RCU is also based on some lock.
I can collect the data into a separate map and try to copy it to old
map after update. But for readers, how could they know the map is in
updating or not if they don't try to check some condition object (will
fail to work if condition check pass but map is updated during
following access) or retrieve a scoped_lock before they read data from
map? Then it will be almost same as the original lock solution I have
said.
To atomic swap, although I don't know how to implement it, I still
wonder if it's safe enough to the following scenario:
1) Thread 1 is reading data from the map via the old pointer of map,
then it is suspended by OS.
2) Thread 2 begin to update and swap the pointer to the map to a new
one.
Then can Thread 1 work well if it's copying data from the original map
when it's interrupted?
To stl::map or some other implementation of map, read the old map may
cause some memory access violation error.
like it) and replace the content in the map with the new content. The
to implement. Just make sure that the threads hold the lock for the
pointer to point to the new map. If you use a smart-pointer you can even
value as long as you read using the same pointer. To make sure that the
(might not work with a smart pointer) or a rwlock. This solution is a