Re: CMap - can it do this?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Mon, 9 Jun 2008 07:47:27 -0700, "David Ching"
<dc@xxxxxxxxxxxxxxxxxxxxxx> wrote:

"Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote in message
news:ie4p44t376bs2nn4l6ut0rh50s211hmjkt@xxxxxxxxxx

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
.

Relevant Pages

  • Re: Using OCONV(,U50BB) in CALLX
    ... It has to do with some caching of pointers for flashed BASIC code. ... I found an alternate way to clear the cache. ...
    (comp.databases.pick)
  • Re: C++: 64 bit performance vs. 32 bit
    ... There might be some workloads that benefit from all this work, but it seems like a high price to pay to reduce the cache impact of 64-bit pointers. ... the Linux kernel does something similar to what the OP asked. ... registers avoid would all be cache hits. ...
    (comp.arch)
  • Re: Should we build i386 or i686 rpms?
    ... > James Wilkinson wrote: ... >> cache, slightly slowing things down. ... I don't have any AMD64 ... to pointers, longs, immediate constants, and some longer instructions. ...
    (Fedora)
  • Re: mmap file at fixed address
    ... > I could also go through all structures and fix the pointers based on the ... > current and last address of the mapped file, but I think that's a bit ... > later recreate the cache, but I'd rather try to make it work the mmaped ... relative pointers ("stem+leaf" addressing.) This is handy because ...
    (comp.os.linux.development.apps)
  • Re: dead zone
    ... IIRC, this is the type of thing they are doing, and as Jim mentioned: it improves performance because more pointers fit in a cache line, ... For IBM-MAIN subscribe / signoff / archive access instructions, ...
    (bit.listserv.ibm-main)