> Personally, I avoid sharing mutable data between threads if I possibly can. > It can quickly turn into an unholy mess. > > —Jens
The key to not just safe but performant multithreaded code is to redesign your data structures and algorithm so that you need not synchronize at all. Many problems do ultimately require some locking but close examination often yields the insight that it doesn't need to be locked in as many different places, to be locked for as long when it is locked at all, or locked as frequently. If you start with a straightforward single threaded solution to some common problem, break it down into multiple threads so as to share the load among multiple cores then add locks where you think they are necessary you are unlikely to ever get all the threading bugs out. But there are often ways to divide up the problem so that many of the locks you thought you needed turn out to be unnecessary. Just acquiring a lock takes time and will require costly context switches into and back out of the kernel even if the acquisition succeeds. if another thread attempts to acquire that same lock it will totally block until the lock is released by it's original owner and that second thread's acquisition succeeds. During the time it is blocked that thread is not serving your user's needs. If you have to wait to acquire locks too much you may find that naively designed threaded code is slower than well designed single threaded code, even on multiple cores. If you possibly can replace locking algorithms with what are commonly but incorrectly called lock free algorithms. They use Atomic Arithmetic Primitives provided by the CPU Instruction Set Archetector to manage very short term locks on single words of memory. If a thread performs Atomic Arithmetic on a memory word, it will still lock it but is guaranteed to release that lock on the very next instruction. A second thread that attempts to operate Atomically on the same word will stop cold but only for a few clock cycles. At least that's better than suspending the entire thread, which costs expensive kernel calls and returns. Often overlooked is the performance penalty of maintaining multicore cache coherency. If you've got your locking right you won't have any discernible bugs but if two or more cores read or write the same cache line simultaneously your perfermance will be poor due to all the cache flushing so that all the cores maintain an identical view of memory. To improve performance share as little data as possible, access it as infrequently as possible and if you access it at all, finish what you're doing with the shared data as quickie as you can. The best is to find some way to order access to shared regions so that multiple cores tend not to access the same cache line at the same time. This is all very vague and conceptual so it may not be clear how you need to revise your source so as to heed my advice. But we have always known that hardware can go faster if we use more instances of it, and it is a lot easier to design a computer with two cores than it is to design a single core that yields useful results twice as fast. The literature has rich discussions of concurrent processing going all the way back to the 1940s. The problems you and I face today may well have been solved and published decades ago. Even if the algorithms were patented those patents may well have expired by now. I'm sorry but I cannot recommend any reading. I expect others on this list can. Don Quixote de la Mancha Software of Elegance and Beauty http://www.dulcineatech.com/ quix...@dulcineatech.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
