One of the surprising things about the multi-processor era is how poorly some applications handle it.
Case in point: I adore Shiira and use it as my everyday browser, and overall it’s a compelling browser, even if I do have to fake the user-agent to get annoying Ajax-based sites to let me in. I think of it as “Safari with the training wheels taken off”. However, printing in Shiira is fraught with peril. More often than not, printing a page on my dual-G5 crashes the application.
The funny thing is, printing almost never crashes on my G4 PowerBook.
While I was dumping some photo pages to PDF in preparation to letting my .Mac account expire (face it: .Mac sucks, and wouldn’t be worth $20 a year, to say nothing of $100), I found that I was printing them without crashes on the PowerBook. Initially, I thought it might be the processor generation difference, but then I thought to turn off one of my G5’s with the Processors system preference:
Surprise. Much less crashing. Maybe 1 time out of 20. Which is still too much, but I had been crashing 9 times out of 10.
Seems like it has got to be a concurrency bug. What made me think to turn off a processor goes back to when I had the opposite problem working some QuickTime stuff with a client — showing a certain config dialog is a 100% crasher on my Core Solo mini, but my client has a Duo and hasn’t had a problem. I was going to congratulate myself for buying the crappy single-core mini and accidentally exposing myself to the bug, when someone in a talkback reminded me I could have gotten the dual and then just switched off one core to test single-core operation. Oh well, the minis are supposed to be an easy CPU upgrade, right?
I think developers are just coming to grips with some of the implications of multi-CPU development on the desktop. Mastering threading and understanding concurrency is a bigger deal now than it used to be. For example, Java desktop developers often kept their stuff on the main “event dispatch” loop for reasons of performance and thread-safety, but that leaves a lot of potential CPU time wasted in the multi-core era. Smart programmers are going to have to get into the habit of putting work on new threads and having those threads call back to event-dispatch when they’re done. I think the Cocoa case is pretty similar, except that you’re dealing with the care and feeding of AppKit’s main thread… but I haven’t done that much Cocoa programming, so the Java analogy may not be particularly appropriate.
hi there,
almost all desktop app. developers should now be getting dual core or dual processor boxes to test. At the least, testers should get those. Getting testers nice stuff will
a) test for concurrency
b) make it easy for testers to automate stuff while at the same time test those use cases which are currently not automated.
my 2 cents.
BR,
~A
If I understand you correctly, you're suggesting that there's application code (in Shiira and other apps) that looks something like this:
if (dualProcessor) {
// Do something
}
else {
// Do something different
}
But this is not how applications are written. When concurrency is needed, the app simply spawns threads and lets the OS handle the scheduling. The number of processors is normally transparent at the application level.
Now, it may indeed be true that Shiira has a concurrency bug (e.g., a race condition), but concurrency bugs appear on single processor systems, too. So, if an application is crashing on two processors but not one, I would blame the OS, not the app.
Um... Java desktop developers mostly move stuff off of the event thread, to avoid the GUI hanging, and then have it call back when done (at least for any task that won't be instantaneous). Witness the SwingWorker class for doing exactly that.
How do I get access to the processor preferenes pane on a MacBook?
Now, it may indeed be true that Shiira has a concurrency bug (e.g., a race condition), but concurrency bugs appear on single processor systems, too. So, if an application is crashing on two processors but not one, I would blame the OS, not the app.
Interesting take on this from an old Dr. Dobbs article on concurrency:What usually doesn't get caught in testing, however, except in shops that understand why and how to do real stress testing, is those latent concurrency bugs that surface only on true multiprocessor systems, where the threads aren't just being switched around on a single processor but where they really do execute truly simultaneously and thus expose new classes of errors. This is the next jolt for people who thought that surely now they know how to write concurrent code...
Trevor:
You do not understand threads correctly. An application that uses multiple threads can very easily have bugs that only manifest on a multi-processor system. It has nothing to do with the OS.
On a single core uni-processor system only one thread can actually be executing at a given point in time. But true concurrency can happen on systems with two or more cores or processors.
Jamie:
Download and install Apple's CHUD developer tools.
http://developer.apple.com/tools/download/
I think it's the same bug I just debugged in my tool Find It! Keep It!, a webbrowser that lets you save pages to a database by pressing "KEEP IT", and lets you search for them later by tag or content. I've explained it on my blog and am trying to contact Shiira's author so that he can fix it in Shiira.