It must be a deadlock kinda day. Pete McKinstry points to a Java deadlock avoidance scheme which involves knowing and using a total ordering of the locks that you wish to acquire. This is similar to Andrei Alexandrescu’s C++ idea of always acquiring multiple locks in increasing memory address order.
Both of these are fine if you can get at all of the locks from one place. I find that that’s rarely the case and more often the locks are within objects and I don’t want to break the encapsulation to expose the need to lock around a method so that I can grab the lock that’s inside of the object and then use it from outside of the object in some multiple lock, deadlock avoidance, total ordering, code based lock scheme… In my opinion these ideas are all well and good in theory but just don’t tend to work in practice if you are working with properly factored code….
I’m currently adding some functionality to a server that I wrote, using The Server Framework, for a client last year. The server provides application gateway services for them. The new functionality is to switch to using asynchronous connect calls using ConnectEx when it’s available on the platform that the server is running on and to continue to use a blocking connect if ConnectEx isn’t available.
As I mentioned in the posting back in Feb 2004 the performance counters that we add to these kinds of servers are invaluable in tracking down problems.
I’m glad that Brian Button went to the trouble of writing this post and thinking through the implications of shared setup and teardown code in tests. I’ve been a bit concerned about some of my tests for a while now. You see, I don’t use a fancy framework, I just write them myself in C++ and generally there isn’t much shared setup code because I don’t find it that useful. Brian’s insight that the duplication present in tests is often a good thing because it allows the test to communicate more clearly is pretty much what I’ve thought for a while.
From C++ Potential. In a posting about changes to the compiler switches in Visual C++ 2005 Brandon mentions that they’ve removed the single threaded C runtime library options.
Does anyone out there use the single threaded CRT anymore? I can’t remember when I last used it. I doubt this will cause me or my clients any great problems and I guess VC6->VS2003 still works ;) for those for whom it is an issue.
Simon says; I’ve stopped using ?: because it isn’t as readable as an if .. then .. else.…
I, personally, don’t find the readability of the conditional operator (?:) a problem. No more than I find readability of assignments or pointer operations a problem. I can see how that since the conditional operator is only appropriate for use in certain circumstances, some programmers may not have come across it very often and for them it may be harder to understand than a construct that they know well.
Simon is thinking about using unit testing to help with performance testing. Whilst I’ve found it useful to use unit tests as very focussed ways to run a profiler on a selection of code I don’t think it’s a good idea to tie the success of your test to it completing within a particular length of time.
After all, you might decide to run all of your tests under a tool such as Boundschecker and it would be a pity to get false failures due to the fact that the test is running slower just because you’re using some other tool or running on some other machine.
Robert Scoble, and others, are discussing blog search engines at present. It’s quite interesting to see that there are lots of different approaches to the same problem. Mary Hodder’s article is good in that it explains a bit about the differences in how Bloglines and Technorati get their figures. I guess it’s early days in the blog search engine space but none of the existing offerings really do what I’d like ;)
Richard Hale Shaw is writing some blog entries about moving away from C++ (to .Net). But then he would say that, wouldn’t he. His job includes providing courses for people learning .Net… ;)
Anyway, I’m sure it’ll be an interesting series of articles, especially given his current views on C++…
I think Richard’s being a bit harsh to say that C++ is just a procedural language with an OO retro-fit. Sure, you can write procedural code in C++, but then you can do the same in most OO languages if you try hard enough.
There’s a rather disappointing article on .Net sockets in this month’s MSDN magazine.
Updated 5th May 2023 to fix broken links
The title of the piece is “Get Closer to the Wire with High-Performance Sockets in .NET” which nicely over-hypes the content. How, exactly, am I getting closer to the wire by placing a managed layer between my code and the wire? The summary box is a little more honest; describing the article as covering “basic socket programming” and “factors in creating socket-based servers” which it does…
Sahil Malik doesn’t agree with Jeremy Miller’s description of excessive tracing being a code smell. He suggests a ’neat’ way to get around the problem but, IMHO, he’s completely missing the point, and I’ve said as much before. Oh, and I agree with Rockford, the ’neat’ way stinks ;)
Firstly, Sahil seems to have misunderstood the smell. It’s not seeing the output (which is what his ’neat’ trick avoids) it’s having the log statements in the code in the first place.
