Replies

I believe that .6’s increased emphasis on threading/scheduling on multi-core products is aimed at the weak spot for both Windows and Linux. The only OS that has a *really* good threads/scheduling infrastructure out there just now in the Unix space is Solaris. Everything else is a step down from there.

If OS X could really go after this issue, it will be an entry into the database server market. Right now, if you want to run Oracle on multi-CPU/core iron and get your money’s worth, you choose Solaris for the threading.

That said, writing multi-threaded apps is something that is beyond the ken of many programmers. Apple is laying the groundwork first in the OS, but to capitalize on this, I think they’ll need to come out with some slick tools in the development suite to help programmers unfamiliar with multi-thread programming to ID the weak spots in their code; things like locking, resource contention, cache coherency, etc.

I think they’ll need to come out with some slick tools in the development suite to help programmers unfamiliar with multi-thread programming to ID the weak spots in their code

I don't know what they plan in general, but right now OS X just does it for you in some cases. The one I know is in Core Animation, which automatically multithreads calls to it (and automatically GPU-accelerates it). Your program doesn't even have to be multi-thread aware.

But for general programming I would appreciate something better than in Visual Studio. VS helps a bit at run time, such as catching some illegal cross-thread data access, but it's not all-encompassing. The Background Worker simplifies basic threading, but is also mainly a solution to the Windows problem of your UI operating on the one and only main thread. Locking and race conditions are still possible, and hard to catch.