A Stitch in Time

I have written a bunch of multi-threaded code in the past few years. (I realize that a "bunch" isn't very quantifiable, but bear with me.) It seemed to work fairly well; the server product I worked on was able to make use of multiple CPUs whenever possible. I tested it on multiple CPU machines and saw all CPUs being fully used under load. Also, others used that product on 8-way boxes with good reliability. I have found and fixed threading bugs in my own code and in other's code. I still, however, find myself looking for patterns to help me deal with threading, to increase my confidence in my (and other's) multi-threaded code.

I don't know if it is the indeterminacy of it, or if it's that I don't feel I can hold a lot of multiple states in my head at once. I also know that the few times I've tried to have my threading code reviewed by others they gave up long before I got any feedback of any kind. I don't know if that was because the code was opaque (though there wasn't very much of it...) or because they weren't able to deal with multi-threaded code any better than I was.

I had a number of concerns about the use of mutexes in that product. My primary concern was the sheer number, both of types and of instances. I felt that I had to make sure that the whole system couldn't deadlock, but given those numbers there was no way that I (or anyone I know) could do that.

The principles I will follow in the future are as follows:

• Don't be afraid of multiple mutexes.
• Do as little as possible while holding locks.
• Never hold a lock infinitely.

I don't know if this will make it easier (and more comfortable and reliable) for me to work on multi-threaded code, but I know I can't go about it as I have in the past.

[title reference]

Visual Basic command parser example

OK, I left the Visual Basic version of this code as an "exercise for the reader," but it turned out that I needed it myself. I translated (by hand) the C# example but couldn't get the Visual Basic version to find the method in the InvokeMember call (even after the FindMembers call had found it). I poked around some more, thinking that once I had the MethodInfo I should be able to use it directly without having to use InvokeMember.

Sure enough, after poking around a bit I found Invoke (on the MethodInfo itself), and it works like a charm.

Maybe some day when I'm feeling more ambitious I'll go back and rework the C# example to match the Visual Basic example, but probably not until I really need to. I actually hope I don't, because that means that I will have a need to use C#, and I'd rather stay cross-platform with something like Java, C++ or Python.

The Third Commandment of Blogger

Don't use Blockquote!

I'm still struggling to figure out what Blogger is doing to my formatting. I'm
not sure if it's this particular template, or something deeper down in Windows, or perhaps some backwards compatibility issue.
I say "deeper down in Windows" because I see the same effect in both Internet
Explorer and Firefox on my Windows XP machine. I don't (currently) have any Linux desktop machines to test this.

First, every time I try to use blockquote both browsers show succeeding paragraphs with a tighter line-spacing than the previous paragraph. This happens with the default font; I haven't tried other fonts because no one it paying me to test this stuff. This paragraph is an example of this effect. Secondly (because of its definition), blockquote takes line endings literally, making for some very strange line breaks as shown above. I like indention to set off text, but not when it comes with this side-effect.


For commandments One and Two, see my previous post. That post shows the same incorrect line-spacing in the numbered list. Also note the extra line-space above this paragraph, which seems be be caused by saving and then re-editing the post. Well, at least I'm not paying anything for these bugs.

We Don't Need No Stinking Comments

I am trying to put together some coding standards for the company where I currently work. Yeah, another exercise, but not (I hope) a futile one. As always happens, someone wanted to have a standard for comments.

My only answer to that was this: "If a program acts differently from the way the end-documentation says it should, which do you trust?" I feel the same way about comments. It's not that I don't appreciate them, but I just don't trust them as much as I trust the code. Admittedly it's usually a harder slog through the code, but once you've figured out what the code does, the comments are usually not useful.

As Kernighan and Plauger say on page 142 (1974 edition) of "The Elements of Programming Style:"

The problem with comments that do not accurately reflect the code is that they may well be believed subconsciously, so the code itself is not examined critically.

I wish I could come up with some good way to measure the effectiveness (or in-effectiveness) of comments, but I'm just going to have to go with my gut on this one. I don't think we can have any standard for comments that anyone will agree upon. We may be able to come up with some recommendations, but as for enforceable standards? In "The Practice of Programming" (Kernighan and Pike, 1999), page 24 generously says:

Comments can be useful, of course.

And the rest of the page goes on to show some good usages. This page, however, is surrounded by a list of things NOT to do with comments. Seems like it's easier to tell people what not to do, rather than what to do.

[If you don't know the American pop culture reference from the title, check here or here.]

Technology for Good and Bad

I closed an account at Bank of America a few months ago. After I showed my driver's license to the teller, he swiped it through the magnetic card reader at this station. Perhaps I haven't been dealing with banks and bank tellers much lately, but I was intrigued and amused.

Then, of course, he proceeded to try to sell me a Bank of America credit card. I told him I already have enough credit cards and he proceeded to enter that little bit of information into his terminal.

Perhaps the programming elves at Bank of America implemented the "read the DMV magnetic strip" as an ease-of-use measure, or perhaps they are trying to reduce the number of data entry errors by their front-line people. In any case, it certainly made it easier for me, since I wasn't carrying the bank card that came with the account.

This use of technology I appreciate.

I didn't, on the other hand, appreciate Bank of America making the teller try to sell me something, and I certainly didn't appreciate that they then make him record why. I've already had to deal with a number of telesales calls from them (until I told them to put me on their Do Not Call list). I wonder if my interaction with the teller just took me back off their Do Not Call list. If so, I'll just go through getting off it again.

Appropriate Technology

One of the side effects of having a Prius with the radio-key is that I sometimes leave the key in my pocket. When I leave the car I don't need to pull the key out of the slot, so I had a personal pattern set where I just get out, close the door and press the Lock button on the outside of the door.

Once (and only once) that got mixed up with my personal pattern for our van. I got out of the van, pressed the lock button on the inside of the door and merrily shut the door. It was only later that I realized that I had locked my keys into the van. What about the warning buzzer, you ask? Well, it has been malfunctioning for a number of years now, and always buzzes when the door is open (regardless of the state of the keys or the headlights). The van is old and I want to spend as little as possible keeping it running.

I called AAA and they sent one of their guys. He got out of his truck with a little pillow with an inflater bulb on it. I watched in fascination as he slid the pillow between the door and the pillar and inflated it to force the door open just enough so he could get a long plastic wand through the opening. He then used this wand to push the Unlock button on the door. Nothing electronic at all.

Much to my chagrin, I had to call AAA again later that day when I went to leave work and found that I had also left the lights on. I hadn't noticed it at lunch.

Maybe I should get that buzzer fixed.

What I Learned Today

I started using the Lightning calendar add-on with the Thunderbird email client a few weeks ago, and have been wondering what the "CW" stood for in its date display.

Country Western?
Conventional Wisdom?

Used Google search and after going through a few search terms that either gave me too much or too little, I used "calendar CW lightning," which turned up this:

https://addons.mozilla.org/en-US/thunderbird/discussions/comments.php?DiscussionID=7662&page=1#Item_0

Ah, "Current Week!"

... and today's rant...

If I had time, I'd love to work on the Thunderbird text editor. I've gotten to the point where (if I'm going to use any formatting) I just compose my emails in Word, paste them into Thunderbird and then clean up as necessary. I do this because I have not yet been able to figure out how Thunderbird stores its formatting, and I can't find any way to make the "markup" visible. Is this because Thunderbird uses some low-grade Microsoft editing control, or some other reason? (Not that the editor in OutLook Express, or whatever its current name is, is much better...)