The deadlock detection tool that I was working on last week is coming on nicely. I managed to locate two potential deadlocks that had never caused any problems in code that is running live on a client’s site. Once I had a report from my tool it was relatively easy to fix the problems. Both of these were real bugs that just hadn’t bitten yet.
Today I added some rudimentary lock contention monitoring to the tool and the results seem to be quite useful…
As I mentioned in an earlier posting I’ve been working on a tool this week. I’m too lazy to do a job manually and so I decided to write a tool to help me do it…
Note: the deadlock detector mentioned in this blog post is now available for download from www.lockexplorer.com.
The tool is designed to help me track down deadlocks in code. I decided I needed this tool because I wrote a piece about debugging deadlocks in Visual C++ and realised that using trial and error to locate deadlocks in some client code simply wasn’t good enough.
There’s an interesting post over on the Joel On Software forums about RAII in C++. The original poster’s problem is clearly stated in the first line of their question:
When the constructor for CTheClass runs, I want to acquire 3 resources. These 3 resources will be freed in the destructor (that’s RAII, right?)
Wrong.
The question goes on to point out that if one of the constructors of one of the resources throws and exception then, because the CTheClass constructor hasn’t completed the CTheClass destructor doesn’t run and the resources that were successfully allocated aren’t released.
Ahsan Askari asked the following in a comment to one of yesterday’s posts:
Just like to know whether you use external libraries specially ‘BOOST’ in your commercial projects and related pros-n-cons ?
*
*Also i like to know your initial strategy of Software development. I mean you’ve written a lot about your coding and tsting techniques but i like to know how you start the project, whether you believe in UML and how you carry out analysis.
I’m still reading someone else’s code and it just struck me that a lot of ‘strange’ coding practices become unnecessary if you factor your code ‘correctly’. Note that both ‘strange’ and ‘correctly’ live in the Len::Personal::ViewOfTheWorld namespace…
Take this, for example:
// show line number info, NT5.0-method (SymGetLineFromAddr64()) if (this->m_sw->pSGLFA != NULL ) { // yes, we have SymGetLineFromAddr64() if (this->m_sw->pSGLFA(this->m_hProcess, s.AddrPC.Offset, &(csEntry.offsetFromLine), &Line) != FALSE) { csEntry.lineNumber = Line.LineNumber; strcpy_s(csEntry.
I’m looking at some code to help me understand how to use the dbghelp.dll Windows stack walking and symbol discovery stuff and the code I’ve found on the net uses a programming style that I’ve seen a few times before and have never understood the reason for.
if (this->m_sw->pSGSFA(this->m_hProcess, s.AddrPC.Offset, &(csEntry.offsetFromSmybol), pSym) != FALSE) { strcpy_s(csEntry.name, pSym->Name); // UnDecorateSymbolName() this->m_sw->pUDSN( pSym->Name, csEntry.undName, STACKWALK_MAX_NAMELEN, UNDNAME_NAME_ONLY ); this->m_sw->pUDSN( pSym->Name, csEntry.undFullName, STACKWALK_MAX_NAMELEN, UNDNAME_COMPLETE ); } else { this->OnDbgHelpErr("SymGetSymFromAddr64", GetLastError(), s.
*Piracy is not an enemy until you are famous.
Until that point, obscurity is your enemy.
I think independent creators should spend all of their attention fighting obscurity until they are famous, and only then should start to worry about piracy.*
Derek Silvers, via microISV
Kevin Barnes has written a nice piece on “freedom” languages, his word for Ruby, Python, Perl, etc. He compares these with “safety” languages, such as C++, C#, Java, VB, Delphi.
He starts off by saying “I picked the terms freedom and safety because they represent a philosophical split that I’m not sure some of the advocates of these languages realize is present. You can sense this split when you listen to the words that the various pundits use when discussing the merits of different languages.
A while ago I came across JLR’s weblog and read his three postings using interfaces in C++ (1, 2, 3). I fired off a quick comment on the first article because I didn’t agree with a couple of things he was saying. Jose’s response to my comment grew into this posting and, well, now I need to explain my position in more detail.
This is it…
The first point that Jose takes issue with is that I dismiss his use of macros without explaining why.
This is a nice piece by Tim Anderson on why COM is still alive and kicking despite what all the .Net-heads would have you believe…
It always seemed to be pretty obvious to me that all the “COM is dead, long live .Net” hype was just that, hype. Whilst there are obvious advantages to using .Net for new projects there are a lot of projects out there in the wild where you can’t just throw away all of the investment that has been made in COM.
