Re: Smarter CSingleLock?
On Fri, 11 Apr 2008 09:37:04 GMT, Your Name <none@none.none> wrote:
Well, only the writer thread actually writes to this "count" value, and
there is only one writer thread. So, even though it may take multiple
instructions to actually accomplish "x++", I don't really care precisely
when the increment happens, as long as it is *after* the data structure
itself is intact. In the worst case, a reader thread reads the un-
incremented value. The reader threads are rendering the various data to
the screen at ~60 frames/sec, so the worst that happens is that the new
data (at the end) is displayed one sixtieth of a second later than it could
have been. Unless I'm misunderstanding (entirely possible), there's no
danger of corruption.
That's what I suspected in my first message when I said, "You would still
need to use memory barrier instructions on multiprocessor systems with
weakly ordered memory subsystems, e.g. Itanium." The problem is that absent
memory barriers, there's no guarantee that your reader threads will observe
the writes in a timely fashion, and even if they do, the related data may
not be available at the same time. So, you might observe the incremented
count but not the new data, even though you perform the increment after the
update. This can happen even on x86, for a different reason: compiler
optimizations. That is, even if you're careful to increment the count only
after writing your new data, the compiler may be able to reorder
instructions and move the increment before the data update. Finally, I'm
still interested to know, "How are you keeping the readers at bay while
you're incrementing, and how do you release them?"
--
Doug Harrison
Visual C++ MVP