Subj : Re: Recursive lock?
To   : comp.programming.threads
From : Michel
Date : Fri May 20 2005 10:31 am

doug wrote:
>>Event though I work primarily in win32 land I wrap and isolate all apis as 
>>well, for  a lot of the reasons you mention, and to get a C++/exception 
>>safe interface. Actually i don't see why It would hamper performance or be 
>>as fast as native, at least not when diagnostics is compiled away.
> 
> 
> absolutely true - my mishtake!
> 
> 
>>But what typically does the wrapper do on double acquire (assert, throw)
> 
> 
> We assert and bring the server down.  We get a stack trace of all threads 
> and a core dump (on suitable OSs), and on a diags build we get information 
> on who is holding what.  (plus a load of other stuff.)
> 
> We view things like this as coding errors, so kill the product asap, so 
> there's no chance of missing it.

This sounds like a reasonable approach, and the one that spring to my 
mind as well.

Another question is how you identify the locks/sections in the output 
log files?

> Well, there's a lot more code running when you do these debug checks.  You 
> have to lock around these checks too. All this adds up a rather different 
> profile when you're running the code.  It's good, but it's not rock solid - 
> there's still a chance that a bug doesn't show up in debug testing due to 
> the code differences, and doesn't show up in release builds until you ship 
> it.  Lovely.

Amen, I think a lots of us has been up late nights to find those kinds 
of bugs.

> This type of bug would typically not be a double acuqire, invalid free, or 
> hierarchy violdation - *as long as you cover every single code path in your 
> debug testing*.  Rather, it'd be a performance or scalability problem.

I most often see race conditions crop up in release builds, but as 
experience builds up these should be rarer.

/Michel

.