Is Threading Going Away?

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...

Since this style of "parallellizing" execution is really about performing vector oeprations I doubt we'll be seeing the demise of conventional threading soon.

Optimizing vector operations this way may be nice, but they don't apply to most classes of problems. Usually where they're beneficial is "inside" some componentized facility: a DBMS engine, a sort/merge engine, an encryption engine, image processing engine, etc.

Of course people doing simulation and modeling or things similar to that will have a lot more use for ad hoc vector optimization.

Parallelism is only useful in cases where you can have two things operating in parallel... for what I suspect is a great deal of us, it's not very useful.

I don't see how that impacts threading. I don't think the days of Threading details are numbered. I think threading has already been trivialized - especially in VB. It's easier than before to spin up a thread and let it do its thing. More often than not, when people get into trouble with it, is when they cross-thread while trying to update their UI. That's something you do once or twice, learn your lesson and you remember where you "did that once before and have the solution."

-tg

An example of what I was getting at was sorting using a divide and conquer approach.

Sometimes a huge list could be broken into one shorter list per execution unit (processor, core, hyperthread, etc.). Then each sublist could be sorted separately, and finally after that is complete the sublists can be merged back into a final complete sorted list.

This can be much faster than just sorting the list "in one go" and many sorting algorthims do sort/merge kinds of things anyway - we just get to use (up?) the other processors to get things done quicker.

I agree with the earlier points. When I have used threading, it has been to perform a different process that would run for a potentially long time. Parallelism has no real bearing to that. If I was running several of those processes in a loop, then they would lend themselves to parallelism, but most of the things I thread don't run in a loop of that nature.

As one example, I have a UDP class that runs a thread which listens for an incoming packet. Once a packet is received, the thread decodes the packet, places it in a queue, and exits. Its very last act is to spawn a new instance of itself, which means that a new thread is now listening for a packet on that socket. How could parallelism help in this case? I can't have more than one listener on the socket (I could, but it would be silly, pointless, and error prone), nor can I do without threading at all, since the listening blocks the thread it is on, so it can't be in the UI thread.

Massive parallelism has several potential benefits, but I still think for the most part programs are going to be very serialized for the time being. I agree that loops are the biggest thing that can take advantage of parallelism though and will in the short-term help immensely.

I agree though, I see a time where the compiler and the OS will manage all parallelism without any forethought from the developer. You won't even need anything like .AsParallel() if the compiler becomes smart enough to figure it out for you and just do it.

The concepts of parallelism and threading, and the challenges they present, have been around for a long time. Both of these concepts, will IMHO be around in some form for a long time. Over the years more of the details of the mechanism(s) gets hidden.

When I first started writing VB .Net programs and doing threading I had a hard time understanding cross-threading errors. Because of my background I would never conceive of having two threads, parallel or otherwise, touch the same piece of memory without controlling it. It is still frustrating at times to have all UI updates controlled by forcing those updates into one thread. But they aren't writing .Net for me.

Quote:

---

Originally Posted by Jenner

I agree though, I see a time where the compiler and the OS will manage all parallelism without any forethought from the developer. You won't even need anything like .AsParallel() if the compiler becomes smart enough to figure it out for you and just do it.

---

It would have to be REALLY smart. Many loops that I run (it feels like about half, but I have never done a quantitative study, nor shall I now) are sequential with the option of leaving the loop early if a certain condition has been met. It would be difficult to perform that in parallel, and hard to determine whether there was any benefit.

I can think of one example that parallelism would've helped me. In writing a program to calculate factorials I used prime factorization, and to get the primes I created a Sieve of Eratosthenes. It would, I think, be easy to make that several parallel processes.

Another place it would seem to make sense is somewhere you were doing a lot of IO to various different sources.