Hi Everyone, thanks for the responses. A few things:
1) I am currently using r/w locks (and are implemented through
automatic objects so destruction is guaranteed) but the numbers came
from stress testing all writes so it doesn't make much of a difference
in this case. That said, are there any standard r/w lock impls that
people are using (my current platform is Windows).
2) Total time doesn't really matter because this function will be done
in a background thread. Obviously it can't take hours but several
seconds are acceptable if lock time were, say 10ms or better.
3) I'm currently using google's dense_map for this impl.
4) What I'm really after is to be able to sort the hash_map (in real
time) so I can prune it based on a given criteria (think cache
scavenging). I suspect the best way is to snap_shot the data and work
on the copy, but perhaps there's a better way.
5) Are there any usable strategies that could iterate the map multiple
times, locking minimally per iteration, to produce the desired
effects?
> Three things came to my mind:
>
> * You could try:
> lockResource(map);
> const std::map<[...]>::size_type sz(map.size());
> unlockResource(map);
> vec.reserve( sz );
> lockResource(map);
> vec.insert(vec.end(),map.begin(),map.end());
> unlockResource(map);
>
> I.e. factoring the allocation out of the critical section. It does not
> really matter above, whether the map changed its size inbetween the
> two guarded sections. Note that here "std::vector<>::reserve()" is
> used instead of "std::vector<>::resize()" in your code. Therefore I
> must use an insertion command that adapts the size, so "std::copy<>()"
> won't do anymore. Please note, however, that you may win less than it
> seems at first sight because memory allocation on freestore implies
> locking - go for malloc implementations that are optimized for this
> case.
>
> * If you do not need consistency in time you could go for a (non
> standard) container that sup****ts fine grained locking instead the
> above coarse grained approach: Read e.g. the PhD thesis pointed to at
> <http://www.freidok.uni-freiburg.de/volltexte/41/>
> about red / black trees in concurrent applications (in German only).
> So given your container sup****ts a robust iterator, your "copy" could
> contains the contents of the map as seen by the iterator as it travels
> through the map while the other branches of the map might change in
> parallel. This might not be acceptable for your application, however.
>
Thanks, I'll take a look.
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
