English | 中文 | Русский | Français

2,555 Posts served

8,264 Conversations started

Less Focus on Threads More Focus on Tasks

By Robert Chesebrough (Intel) (8 posts) on April 24, 2009 at 12:52 pm

Several years ago, when I looked for training courses on the subject of parallel programming for shared memory systems I found few courses being offered.  Some friends of mine and I did find a very nice course from a 3^rd-party vendor on threaded programming.  The course mainly focused on "C" and using POSIX threads to explicitly manage thread creation.  The course did touch on higher level concepts such implementing a producer consumer using semaphores - but on balance - my recollection of the course was how I had to manage threads as developer. Even thread pools were largely self created & self managed. The training reflected the level of maturity of the shared memory parallel programming state in the late 90's early 2000's. The key topic in this training was: Threads!

As I scan the horizon lately, I see an interesting pattern has emerged.  Tools such as Threading Building Blocks, the new OpenMP 3.0 spec and the Executor interface from the Java.util.concurrent package, to name a few, are providing ways for developers to specify tasks to a library or runtime and allowing the library to manage the assignment of execution agents (threads) to these tasks.  The central concept now: Tasks!

What are tasks?  Tasks are logical units of work.  A task may be a function call, it may be an iteration of a loop, or it may be a block of code encased in curly braces.  Tasks are the job assignments, in code, the developer wants to accomplish.

The trick to parallel programming is finding as many independent tasks within an application as possible and then in finding as many dependent tasks as possible that can either be ordered or provided with some synchronization constructs that effectively make even these tasks conditionally independent.

So training for parallel programming going forward, I would argue, should focus more and more on tasks and less on threads; more on teaching developers how to identify independent tasks, and less on how specific explicit threading implementations. I believe we are reaching the point where we can grapple with the higher level abstraction of tasks and have some confidence that I can rely on a library or package to handle the thread assignment and thread management activities automatically.

Does this mean I can forget about Threads?  No.  At this point, knowledge of threads is still required to know how to deal with tasks that are not completely independent.  A basic knowledge of threads, in so far as knowing that threads can run in any arbitrary order, is at least required to understand the possible side effects to threading such as race conditions or dead lock conditions.  Proper synchronization of threads to data is key to eliminating these traps and synchronization on a shared memory system requires a knowledge of some threading API to create mutex or critical sections, or what-have-you.

At least, that’s my take.  What is yours?

Categories: Academic, Parallel Prog. & Multi-Core, Software Engineering, Threading Building Blocks

Comments (4)

April 24, 2009 10:16 PM PDT Vitaly Dilmukhametov Total Points: 180 Status Points: 130 Green Belt

Yep! I think, "task-based" paradigm is a right way to build applications. IMHO, every qualified software engineer must understand the "nature" of Tasks - it's based on threads. Task is a higher level abstraction, and it give us more powerful look to the whole project. But if we don't know, what is "inside", we may fail :) It's looks like graphics in Windows, for example. You can use WinAPI calls to draw a text. But if you don't know the common approach how the underneath architecture (such as drivers, windows core, etc) work, you can't fix some lower-level related issues. And we remember - higher abstraction level can't solve 1 problem - too many abstractions :)

April 27, 2009 8:05 AM PDT georgetm Total Points: 185 Status Points: 135 Green Belt

I understand if you haven't heard of my project (http://www.fiberpool.de/en/index.html) yet, but even Microsoft announced a user mode scheduler for Windows 7 and a runtime (ConcRT) that will solve the problem of dependent tasks (so called "User Mode Scheduled Threads"). Take a look here: http://blogs.msdn.com/nativeconcurrency/archive/2009/02/04/c.....ows-7.aspx With these frameworks it will not be necessary to make the effort finding the independent parts of a task.

April 28, 2009 11:47 AM PDT Gastón C. Hillar Total Points: 3,056 Status Points: 3,056 Black Belt

Hi Robert, I've borrowed a few concepts from this post and I've added a new post about .Net Parallel Extensions: http://software.intel.com/en-us/blogs/2009/04/28/invoking-parallel-tasks/ I've included the link to your post. :) Cheers, Gaston

June 25, 2009 2:58 AM PDT Raghuraman Total Points: 15 Registered User

I am not sure if this is a question or doubt or clarification. The issue of 'threading' or 'multicore' should never be put to the application developer or the programmer. Programmer is and should be agnostic to the number of the cores or whether the execution can 'use' the multi-core hardware and/or spawn multiple threads. Two current topics are natural 'multi-core' and 'multi-threading' friendly - application like browser with 'tabbed-browing' and 'cloud computing'. Incase of 'tabbed browsing', each tab is nothing but a thread in execution independent of the other tabs. As far as 'cloud computing' goes, the tasks/processes could be and more often independent of each other and thus be 'multi-threaded' by execution or hardware. Need to 'incorporate' multi-threading into programming has already met with lot of skeptics and also arises only if there is a single machine on which a heavy 'compute' intensive job is run. With servers almost 'serving' as minor 'cloud computing' resource, compute resources are occupied well enough to multi-task. I am not sure if each task needs to be 'hair-splitted' into use of multi-threads. 'Tabbed-browsing' is one simple and population application that can exploit the multi-core and multi-threading capability. Apart from this, as skeptics have said - using multi-cores or multi-threading for routine applications like word processing, spreadhseets, presentations or emails is simply a wastage of resources, apart from wasted manhours of 'reforming' those appplications for multi-cores or multi-threads. Obviously programmers dont want to write an application that runs only on 2 cores and above but NOT in single core. I think most of the 'software' tasks of operating systems can and should be offloaded to 'hardware' or multi-cores. This will also help in reduced run-times. I dont think incorporation of 'run-time' identification of number of cores (similar to RTTI in C++) is simply worth it - bang is NOT worth the bang. I agree with Vitaly Dilmukhametov and also that graphics is main 'application' where multi-cores and/or multi-threading can be exploited to the hilt. I also have another thought - though thread is called as a 'light weight process', why not apply the reverse - start a process as a 'thread' and if 'needed' make it a 'process'? Obviously the advantage is that this does not depend on the OS but only the processor. OS will execute as it has started off two processes which it is multi-tasking (parallel, theoretically), but on the hardware it can just be two threads which are running in parallel. Hardware realisation of multi-tasking could be one major feature of multi-cores. Also the programmer need not get involved in this at all. Whether the underlying hardware makes it into multiple threads and executes them in parallel 'realtime' or multi-tasks through s/w, the programmer need not worry about.

Trackbacks (0)

Leave a comment