Re: CMap - can it do this?
On Mon, 9 Jun 2008 07:47:27 -0700, "David Ching"
<dc@remove-this.dcsoft.com> wrote:
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:ie4p44t376bs2nn4l6ut0rh50s211hmjkt@4ax.com...
The solution is for CMap to use an internal mutex
around operations on these cached objects, which I think you'd agree is
undesirable.
I would think a critical section (more lightweight than mutex) would be
enough
It would. A "critical section" /is/ a type of mutex. The term "critical
section", however, is a total misnomer, and an awkward, lengthy one at
that. If I were to talk in Windows-speak, I would say CRITICAL_SECTION and
"kernel mutex" or "HANDLE mutex" or something, but when I just want to
refer to the "mutex" concept, I use the term "mutex". In my MT class
library, I call them "LwMutex" (LightWeight) and "Mutex", and unlike MFC, I
don't derive them from a class that defines operations the former cannot
support.
Also, there would be coherency problems between the cached and
actual values due to the user modifying the actual value, and that's true
even in the absence of multithreading.
This could be fixed by invalidating the cache when the collection is written
to.
My goodness, I realize now that Lookup returns a /copy/ of the value, and
the only way to modify the actual value is with SetAt, which requires
looking it up all over again. It seems the more I learn about MFC
collections, the happier I am to never have used them.
Large key and/or value objects could
grow the map object considerably. A straightforward implementation would
impose a default constructor requirement for both key and value classes.
If you mean to cache pointers to the key and value, then that's not much
different than caching a POSITION. I explained why I don't think that would
be worth doing in my last message and how providing the right
functionality makes it superfluous.
I don't exactly know what a POSITION is, except a handle to a key/value
pair. How much computation it takes to convert that to an actual key/value
pair is hidden, so it might be a lot, and might not be.
Earlier, you 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." In my reply to that, I
wrote, "As for storing just the POSITION, which I'll assume is just a
pointer, ..." Obviously, it would be silly to cache POSITIONs that are
expensive to convert to the values you're interested in, when the whole
point is to speed up access to the latter. In my last message, I gave
several reasons why caching values would be problematic, and to avoid
rehashing (pun intended) the caching of pointers, which is where I supposed
the discussion might turn next, I referred back to my previous discussion
of POSITIONs, which I thought we had agreed for the sake of discussion
/were/ pointers.
--
Doug Harrison
Visual C++ MVP