Re: Smarter CSingleLock?
On Sat, 12 Apr 2008 07:36:32 GMT, Your Name <none@none.none> wrote:
Wow, how unfortunate.
Programs could be orders of magnitude slower if the compiler made all
variable access implicitly volatile with memory barrier semantics. Using
volatile would prevent the compiler from reordering reads/writes to
volatile variables, while memory barriers would ensure the hardware doesn't
reorder things. (Note that volatile normally doesn't imply memory barriers,
but MS took the unusual step of making it do so in VC 2005. The main effect
of this is to help buggy code continue to sort of work on exotic
multiprocessor machines. I say "sort of work", because multithreaded code
that uses volatile tends to have other subtle errors due to the inverse
relationship between the frequency of volatile usage and one's
understanding of MT programming.)
Ugh. Well, currently, all reads, writes, and clears
are wrapped with a CSingleLock. But like I said in the first post, I was
hoping this was overkill and was planning to only block the clear
operation.
But based on what you're saying, it sounds like I'll have to stick with all
operations acquiring locks before proceding. But I will definitely take
Joe's advice and switch to CRITICAL_SECTION over CSingleLock.
I wouldn't abandon RAII, which CSingleLock does provide. I'd either
continue to use the MFC classes or find/write my own wrappers for the
synchronization objects I use. (The latter is recommended, as the MFC
classes have numerous flaws.)
--
Doug Harrison
Visual C++ MVP