Clik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
I think SimonRev's point is that the idea of having a BeginUpdate and an EndUpdate method isn't wrong it's just their implementation that's wrong. But I'm not sure that making their method names...
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
So.... create a flag variable in the class private section that indicates if Updater() has completed, and add a check in the else clause? Then something similar in the EndUpdate() that indicates the...
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
The foolproof solution is to wrap the contents of BeginUpdate and EndUpdate in a critical section or mutex. In essence, you need to prevent two (or more) threads from actually being in either of these...
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
There's an extra word in the title - "it" after "because".
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
Nice! An occasional demonstration the debugger is not magic comes in handy to teach people to understand.
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
Ahh memories of when the first dual-socket Pentium-Pro machines appeared and desktop programmers everywhere discovered that this type of bug is (at least) thousands of times more likely to be observed...
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
@The foolproof solution...: Actually you only have to use the mutex (or some synchronization of kinds) when initializing. So you can actually do double-checked locking to avoid the synchronization...
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
> So what is the foolproof solution?A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
@voo: A correct implementation of double-checked locking requires you to use memory fences to ensure that the processor actually flushes its write queue out, and that the caches are kept properly...
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
@Mike Dimmick - nice, thanks for the additional info!
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
@Mike Dimmick: Yes, but not the Windows CriticalSection API which is dog slow.
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
> This type of race condition is more likely to manifest on multi-core machinesIf you are dealing with JIT debugger / crash dump this is common also for single core machines. There is plenty of...
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
@Mike Dimmick: You can implement mutexes without bidirectional memory fences? No idea about ARM, but on x86 that *should* make a difference, especially since you also need some further bookkeeping for...
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
@voo: The double-checked protocol when done right is pessimistic in that it takes the lock when it can't decide without taking the lock. The only hidden assumptions are the compiler cannot optimize...
View ArticleClik here to view.
re: Various ways of performing an operation asynchronously after a delay
GregM: my understanding must be wildly out of date. How is it 'perfectly okay' to call delete on a 0 pointer? (My ten second experiment crashes, as expected.)[5.3.5(2) says "the value of the operand of...
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
To this experienced multi-threaded developer the example code looks naive, and so there is no wonder it failed.Furthermore, the amazement that the crash-dumper or debugger can lie to you (especially in...
View ArticleClik here to view.
re: Why are there both FIND and FINDSTR programs, with unrelated feature sets?
Of course, nobody wonders why find was written (for Windows) in the first place, since grep dates to 1973, almost 10 years earlier, and is vastly superior. And, yes, the source was available.[FIND was...
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
@Smitty: Perhaps you get that impression because you now have quite a bit of experience, and there exist people with less experience, all of whom presumably fit into your "do not know how to code"...
View ArticleClik here to view.
re: The debugger lied to you because it the CPU was still juggling data in...
"If you actually looked at the memory pointed-to by ESI+8, the value there was not null, yet in the register dump, EAX was zero."I think you meant ECX instead of EAX here, right?[Fixed, thanks. -Raymond]
View ArticleClik here to view.
re: Various ways of performing an operation asynchronously after a delay
Thanks, especially for the reference; I don't seem to be as badly out of date as I first suspected.
View Article