Re: CMap - can it do this?
On Sat, 7 Jun 2008 09:51:48 -0700, "David Ching"
<dc@remove-this.dcsoft.com> wrote:
If a POSITION is a pointer to the actual value, I can't see how caching it
causes concurrency issues, anymore than generally accessing the entire
dictionary across threads. Elaborate?
You originally mentioned "caching the key/value". That causes problems for
unsynchronized read-only access because the values can get out of sync, and
they may not be thread-safe themselves for copying. As for storing just the
POSITION, which I'll assume is just a pointer, how would it work? Inside
RemoveKey(k), would you hash the key the saved POSITION points to and the
function argument, and if they agree, perform the comparison, and then fall
back on the general search? Or would you be optimistic and perform the
comparison first? Wouldn't you also want to do this for Lookup? I guess it
can work if a POSITION is all you store, you're careful to invalidate it
when you need to, and every operation that depends on its value is a
modifying operation, such that the user will have to provide
synchronization anyway for all concurrent access.
When considering caching information internally to a class to speed up its
operations, besides the thread-safety and other correctness questions, I'd
also wonder (a) How much of a speed-up should I expect, and (b) How can I
avoid it? For a class such as CMap, which is based on a hash table, I
wouldn't expect a huge speed improvement, and given the possibility of
spurious hashing/comparing, I'd expect slowdowns in some cases. I'd also
note that I could avoid it all by providing erase(POSITION).
--
Doug Harrison
Visual C++ MVP