One proposed solution is transaction memory, which employs the concept of atomic blocks of code that work in a similar way to transactions in databases. In other words, a snapshot of the data state is taken, then a series of memory reads and writes are processed and logged. Finally a lock is taken by the sytem, the data checked and – if no changes outside of the thread occurred – the logged changes are applied. Then the lock is released. If changes did occur, the whole lot is aborted.
Transaction memory has been around for a while, but purely as a research/ academic concept. Today though, Microsoft launched a new transaction memory blog run by the folks in Microsoft’s Developer Division’s Parallel Computing Platform product group. They plan to add an experimental transaction memory model to .NET. Whetehr this will ever go into production is still unknown, but it should be a great blog to watch for further developments in this area.
Recently, I’ve been reading a fair bit recently about parallelism in software. It has become a real hot topic in many quarters. Microsoft have been making lots of noises about their alpha release of the Task Parallel library for example and Ted Neward recently waxed lyrically on a recent .NET Rocks! show about multi-threading in Java. He recommended that every Java developer should read “Java Concurrency in Practice” (ISBN 978-0321349606). So why is concurrency becoming such an important topic? The answer is simple: single code systems are rapidly becoming a thing of the past, and the number of cores is predicted to rise exponentially over the next few years.
I stumbled across an article on the Dr Dobbs site today on this subject. As an aside, I was amazed that Dr Dobbs was still going; it was a must-read magazine twenty years ago, but I’d assumed it had long since vanished. The article does read like a Sun advert, but is interesting none the less. The UltraSPARC T2 Plus processor that Sun is shipping in its servers today has eight cores, each of which is capable of concurrently executing eight threads. And two such processors can exist on a single server. That means that we have servers capable of running 128 concurrent threads available now in 2008.
Anyone who thinks that concurrency is an optional aspect of programming, really needs to wake up and smell the coffee. As I’m changing jobs soon and will be switching to a Java development role, “Java Concurrency in Practice” is already on my essential book list. Perhaps it should be on yours too?
If you try taking the following C# code:
|
1 2 3 4 5 |
for(int n=0; n>8 n++) { Console.WriteLine("iteration {0} on thread {1}", i, Thread.CurrentThread.ManagedThreadId); } |
and convert it to use the new parallel for loop:
|
1 2 3 4 5 |
Parallel.For(0, 8, i => { Console.WriteLine("iteration {0} on thread {1}", i, Thread.CurrentThread.ManagedThreadId); }); |
and run it on a computer with four cores, you might expect an output such as:
|
1 2 3 4 5 6 7 8 |
iteration 0 on thread 11 iteration 1 on thread 12 iteration 2 on thread 13 iteration 3 on thread 14 iteration 4 on thread 11 iteration 5 on thread 12 iteration 6 on thread 13 iteration 7 on thread 14 |
You will however be very disappointed with the result if you do, as the whole loop actually runs on one thread in a sequential fashion. It turns out that the reason for this is simple practicalities of getting this stuff working at a basic level for the CTP. As I discovered on the MSDN parallel forum, the reason is that the Parallel.For method breaks the loop up into groups of eight iterations and assigns each group of eight to the next available thread. So if your loop is of eight or less iterations, then it will run sequentially. You can test this by simply adjusting the for loop to 0 .. 15 say and it will use two threads if you have two cores etc.
Once upon a time, most computers had one CPU and life was simple. Occasionally one might get adventurous and use separate threads for the GUI and back-end of an application, but – apart from in some specialist fields – that was about it. CPUs got faster, Microsoft eventually noticed that everyone else on the planet had multitasking operating systems, so they did one too (badly of course), but not much else changed. Then physics got in the way…
Apparently (and I do not pretend to understand the details) we have pretty much reached the limit of how fast a single CPU can go. So chip manufacturers have responded by putting more of them in our computers. These days “dual core” (ie two CPUs on one chip) is mainstream and quad cores (yes, that’s four CPUs on one chip, though Intel seem to feel that “quad core” is a bit too obvious and so go for names like Core 2 Xtreme Wibbly Wobbly, but that’s marketing for you) are not far behind. Given the way these things tend to scale, the number of cores will likely grow thus: 8, 16, 32, 64, 128 etc. So in just a decade or so’s time, we might well have over a hundred CPUs inside our computers. “So what?” you might ask. Well the answer is simple: what are they supposed to do exactly?
Continue reading “Microsoft release CTP of Task Parallel Library”