20060327,00

Get It Try It

Murphy's Law of Multithreading.

A wise old guy from the Boca Raton OS/2 crew once quipped than when it comes to multithreading, Murphy's Law applies in spades. 'When it comes to multithreading, anything not only can but will happen', he wrote. He was too right.

And yet it's a wonder so many (shall we say) 'amateur' programmers don't get it. The goal of programming is to save the user from error - the user should never be forced into a position to save the programmers from error - and yet that's the way it works all too often.

You have to sweat the fine details. That's the name of the game. Small errors get multiplied by the CPU speed.

Look at the graphic on the right. That's Xscan's Filters menu. The top item is for the regular expression for file searches. The bottom two items apply to the seven items in the middle group: the classic Unix holes and one particular to HFS. They're bitwise flags.

It's easy to manage - left shifts and no masking needed.

A while back someone added the two filters Empty File and Empty Folder but forgot to increase the test value for Set All from the previous 0x1f to 0x7f. We just discovered this the other night. So yes, of course it's been fixed.

The code to enable the menu items is intricate if concise. It takes a lot into consideration. You can't have those items enabled during a scan. Scans have to take place in a secondary thread. You can't lock the GUI - all user interaction - while the scan is ongoing. The items have to be disabled.

Which makes perfect sense from the user POV. The choices were made; the scan's in progress. You can't change the criteria in the middle of a scan.

Worse still, the one programming hand might not know what the other hand's doing. One programmer might work on the menu, another on the background details, and neither can count on knowing what the other is doing. And this applies even if the entire project is written by a single individual.

Where does the secondary thread test those flags? Only at the beginning of the iteration or with each file found? You can't know and even if you do, you might not remember. It's bad design. When the scan's on the menu's off - period.

A lot of programs out there don't remember this or don't take it into consideration or don't vett their product thoroughly before release. The user's fearful of clicking the wrong button or item at the wrong time - because there's no feeling the application is going to do what's expected. Just make sure that when you are clicking nothing else is going on.

But that's bad design. It's a piss poor attitude which leaves the user to compensate for the programmers rather than the programmers protecting the user. For accidents do happen. Mice are notoriously erratic creatures. One slip of the finger and catastrophe can be the result.

Never take anything for granted. Disabled toolbar buttons and menu items not only give user feedback, they also prevent disasters from occurring. You have to thoroughly vett your application and attempt the impossible when you test it. Go outside the envelope. Try what no one would have thought of doing.

When it comes to multithreading, anything not only can but will happen.