Subj : Re: Recursive lock? To : comp.programming.threads From : doug Date : Fri May 20 2005 03:29 pm "Michel" wrote in message news:428DAE7F.3020403@swipnet.se... > 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? It's done as a macro, to you have access to __FILE__ and __LINE__ preprocessor stuff. We then have small macros in our text editors to 'jump' to the location in question with a keypress. It sometimes amazes me how much effort we put into infrastructure like this. I reckon about half of our time goes on codecheck stuff like this, regressible unit test frameworks, text editor macros, etc. > >> 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 .