Weaving solutions for multi-threading
November 1, 2012 —
(Page 1 of 3)
Related Search Term(s): multicore
Like rabbits left to their own devices, processing cores are breeding. But for all the proliferation of cores on desktops, in data centers and inside handheld devices, the fundamental problems for developers who have to deal with all those cores haven't changed much.
For years, tools and frameworks have offered solutions to multi-threading, concurrency and parallelism. But unlike some other programming problems, where clear solutions have been selected already, the multicore problem remains one that is better solved through knowledge, skill and experience than through dollars and prepackaged bits. But that's not to say there haven't been some new developments in development.
Due to the complexity of the problems associated with multicore development, many vendors have had to be quite clever in how they offer their solutions. While there is no substitute for knowledge and experience, some companies, such as Microsoft, have found ways to get new multicore supports into their tools for developers who might not be so skilled in multicore development.
Brandon Bray, principal group program manager for .NET at Microsoft, said that there are three types of programmers for which they've addressed multi-core solutions. The first type of developers, which Bray said is quite small, knows how to develop multi-threaded applications, and doesn't need much help. The second is similar, but wants concurrency to be easier. The third type is the largest, and is made up of developers who want nothing to do with multicore, multi-threading or concurrency.
For each type of these developers, Microsoft has managed to craft a way to make multicore development a little bit easier. For the first two types, .NET 4.5's release in September included a new background garbage collector, which improved application performance thanks to the removal of garbage-collection pauses in the runtime.
“Background garbage collection does all the looking through memory while the program is running,” said Bray. “It's making use of extra cores, and it's not something we could have done 10 years ago because most computers only had one processor in them. It’s a default feature when people upgrade to .NET 4.5.”
.NET also includes multicore JIT, which uses data from previous application runs to optimize JIT compilation of .NET applications. This can improve startup time for long-running applications. This also uses extra cores automatically to do the compilation, thus offering developers a quicker build time.
While these two solutions are targeted at more experienced programmers, Bray said that developers disinterested in multicore can rely on .NET to offer them a faster way to do I/O and to take advantage of multicore for that: Async and Await.
“Async and Await are used with C#. The idea is that most developers really think about the code running on one processor,” said Bray. “If I write a loop, I understand how that works. They think of it synchronously, but most of the time when you're doing network calls or file I/O, that I/O time is wasted time where another processor could do the work. Most of us experience that as the user interface being paused. That UI pausing is an opportunity for concurrency.
“The more I can use multicore in these cases, the better. It means I can keep the UI responsive. How do we get developers to fall into this pattern? The libraries you call that involve I/O, like calling a network or a REST API, you'd like that to be put into the background on another processor, and when the task is finished, it executes on the thread pool and the result is just passed back. I never have to pause the UI. This pattern we've built into the compiler, and it tells you where you need to write these keywords. If you call this API, it will force you to use this feature. Developers that don't care are the ones that cause the pausing all the time. They still don't have to care anymore; often, they don't know they're doing some of this concurrency.”
The trouble with Java
Jason van Zyl is in a unique position to observe how Java developers are approaching multicore development in Java. As CTO and founder of Sonatype, and creator of Maven, he has a front-row seat at the world's largest Java repository, Maven Central.
And yet, van Zyl remained convinced that multicore, concurrent and parallel programming aren't being made any easier by frameworks and tools in the Java space.
“I don't think it's ever going to change, in that you need to find pretty smart people who can do the concurrency code,” he said. “Any syntax or changes in the language, like Scala, you need to be extremely smart to use it, and it's just too hard for some people. In the core parts of your organization, you're never going to get around the need for people who have a lot of experience with it and love it.”
But van Zyl points out one area where a new approach to concurrent programming has been fomenting for the past few years: languages as the solution. Specifically, developers have been considering moves to functional languages like Clojure, Erlang, Haskell and Scala.
“There are some advantages to different languages like Erlang,” said van Zyl. “But you always need people who know how to use them. I am not sure you could make a language that's expressible to every developer. I think Scala needs to get their binary compatibility story a little better, but I hear lots of people like it.”
And that is the central problem of choosing a functional language as your solution to the concurrency problem: It's basically just as hard to train or hire functional people as it is to train or hire multi-threaded and concurrency people.
Of course, Intel has some incredibly talented concurrency and multicore people, and the company has long made its work available to the public through its Threading Building Blocks products. This year, however, Java has joined the party.
For many, Threading Building Blocks and Parallel Studio XE tools have been a lifesaver for concurrency and multicore development. In September, Intel updated its multicore tools with new capabilities.