brad jones
Jan 18th, 2010, 12:20 PM
I attended the Indianapolis .NET Developers Association meeting last night. One of the discussion points was on the parallelism features in .NET. The question that was asked was in regard to these new commands in .NET were based on threads. Programming parallel feature has required creating and using threads. When I heard this question, it made me think back to the late eighties and early nineties and memory management.
Back in the "old days" you had to worry about memory management. In fact, if you needed more than 640k of memory&mdashyes "k" as in 1024 bytes per k-- you had to do special processing with extended or expanded memory on the computer. The processors could only easily work with 640kb of memory and thus complex things were needed to go beyond that. Developer would spend days and weeks tweaking programs to get them to operate in under 640kbs. You had to work with memory, you had to understand extended and expanded concepts, and you had to do lots of low level tweaking.
If you are under the age of 30, you might be scratching your head and wondering what I'm talking about. If you are an old C or C++ programmer, you are likely thinking back to the "old days" where you spent hours chasing memory. The bottom line is that today few developers even think about memory constraints let along about the methods around them. You simply just use memory.
.NET includes the Task Parallel Library, which allows you to take C# code like the following:
// Sequential foreach (var item in sourceCollection) { Process(item); } And turn it into parallelized code by changing it to the following:
// Parallel Parallel.ForEach(sourceCollection, item => Process(item)); It also includes the PLINQ features added in .NET 3.0 such as:
var source = Enumerable.Range(1, 10000); var evenNums = from num in source.AsParallel() where Compute(num) > 0 select num; While this is only a little of the code available, you'll see that there is no reference to threads. The concept of threading is destined to be like the concepts of extended and expanded memory. It is destined to disappear.
As developers, the day is coming when you will likely stop thinking about creating a thread and assigning code to it. Rather, you will likely change your thinking to be about processes that your code performs. You will simply identify process and tasks that can be parallelized and you'll mark them appropriately. Threading--or other underlying technologies-- will be taken care of automatically, and the code within the identified processes will be spread across the cores or processors. The developer won't have to worry about the details.
You won't focus on threads; you'll focus on processes and tasks.
You can already see this change in thinking in what Microsoft has done. You can now run code in parallel by simply adding a few keywords. While the concepts of Extended and Expanded memory didn't disappear overnight, neither will threading. However, it is safe to say the days are numbered that most developers will need to think about the details of threading.
Of course, while you won't have to think about threading, you will have to think about parallelizing or running concurrent code!
More... (http://blog.codeguru.com/blog/2010/01/is-threading-going-away.html)
Back in the "old days" you had to worry about memory management. In fact, if you needed more than 640k of memory&mdashyes "k" as in 1024 bytes per k-- you had to do special processing with extended or expanded memory on the computer. The processors could only easily work with 640kb of memory and thus complex things were needed to go beyond that. Developer would spend days and weeks tweaking programs to get them to operate in under 640kbs. You had to work with memory, you had to understand extended and expanded concepts, and you had to do lots of low level tweaking.
If you are under the age of 30, you might be scratching your head and wondering what I'm talking about. If you are an old C or C++ programmer, you are likely thinking back to the "old days" where you spent hours chasing memory. The bottom line is that today few developers even think about memory constraints let along about the methods around them. You simply just use memory.
.NET includes the Task Parallel Library, which allows you to take C# code like the following:
// Sequential foreach (var item in sourceCollection) { Process(item); } And turn it into parallelized code by changing it to the following:
// Parallel Parallel.ForEach(sourceCollection, item => Process(item)); It also includes the PLINQ features added in .NET 3.0 such as:
var source = Enumerable.Range(1, 10000); var evenNums = from num in source.AsParallel() where Compute(num) > 0 select num; While this is only a little of the code available, you'll see that there is no reference to threads. The concept of threading is destined to be like the concepts of extended and expanded memory. It is destined to disappear.
As developers, the day is coming when you will likely stop thinking about creating a thread and assigning code to it. Rather, you will likely change your thinking to be about processes that your code performs. You will simply identify process and tasks that can be parallelized and you'll mark them appropriately. Threading--or other underlying technologies-- will be taken care of automatically, and the code within the identified processes will be spread across the cores or processors. The developer won't have to worry about the details.
You won't focus on threads; you'll focus on processes and tasks.
You can already see this change in thinking in what Microsoft has done. You can now run code in parallel by simply adding a few keywords. While the concepts of Extended and Expanded memory didn't disappear overnight, neither will threading. However, it is safe to say the days are numbered that most developers will need to think about the details of threading.
Of course, while you won't have to think about threading, you will have to think about parallelizing or running concurrent code!
More... (http://blog.codeguru.com/blog/2010/01/is-threading-going-away.html)