Threads Basics (2009)

http://www.hpl.hp.com/techreports/2009/HPL-2009-259html.html

by timClicks • 8 years ago

70 27 8 years ago

hpl.hp.com

gpderetta3• 7 years ago

I knew it was Hans Boehm just from the hp.com domain.

For those who do not know him, he is the co-author of the Boehm garbage collector and one of the primary authors of the C++11/C11 memory model.

agumonkey3• 7 years ago

Pretty career

    Google 
    HP Labs (Researcher, Research Manager) 
    SGI (Software Engineer) 
    Xerox PARC (Researcher)

gpderetta3• 7 years ago

IIRC when he was at SGI, he worked very close with Alexander Stephanov on the STL.

Edit: right, he implemented the rope data structure in the original STL, which never made it into the standard.

taneq2• 7 years ago

Basic rules for multithreading:

1) Don't. You don't need to.

2) Still don't.

3) If you really, really do need threads, keep it as simple as possible and make sure that every access that needs to be synchronized, is synchronized.

I've been programming for a long time now and I've seen precious few cases where multithreading is legitimately a better option, let alone the only option. Usually even then it's just about using more cores.

sureaboutthis2• 7 years ago

So don't, unless you need to, and then it's OK?

taneq2• 7 years ago

Yes, but in many many cases where people think they need to, there's actually a simpler and safer way to do it. Too many programmers see a long running task or an unresponsive UI and immediately declare that threads are the answer, when they're almost always not.

Admittedly they're much more likely to be useful now with so many spare cores on every machine, but they're still a hammer when most problems are screws.

wkz• 7 years ago

IHMO, threads are mostly useful for scaling a workload beyond the capacity of a single core. For all other types of concurrency problems, a single thread of execution using some kind of event loop is usually a better fit.

setr• 7 years ago

Be reluctant to use threads.

_ea1k• 7 years ago

It is amazing how often I've seen developers reach for threading when it really wouldn't solve their particular problem. The downsides regularly outweigh the benefits.

a3n• 7 years ago

But you have to use threads at least once in your career, and until you've done that there will always be an unresolved tension.

cdoxsey• 7 years ago

This is quite poor advice. With Moore's law slowing down multithreading is an important skill for almost any developer to learn.

monocasa3• 7 years ago

Even then threads are rarely the correct architectural abstraction for your code. Something like a work stealing job scheduler that happens to have spun up to the same number of worker threads as cores on the system under the hood generally works way better. That is, there should ideally be only one line in your code base that says "new Thread()" or the like.

vardump• 7 years ago

How about: Use threads, but only in scenarios when it's simpler or when you need to execute on multiple cores on parallel.

mav3rick2• 7 years ago

Lol 3) is such generic advice. It's like "keep your doors locked ". A bunch of things may need atomic updates. Message passing is probably the easier approach.

vnorilo2• 7 years ago

This is all good, but I want to point out that threads are not the unsafe bit, the unsafe bit is shared mutable state. If you can use a model where that is not a problem (data flow arch, STM), threads cease to be scary.

gpderetta3• 7 years ago

Someone has to implement the data flow engine or the STM. The article is about the low-level details (read hardware memory model and basic is synchronisation primitives) required to do so.

vnorilo2• 7 years ago

sure! I was just reacting to the general threading angst in the comments.

jammygit• 7 years ago

My favourite intro to threads is just the Modern Operating Systems text. Fantastic author

dragontamer• 7 years ago

Two big developments in recent years are:

1. SIMD "threads" being programmed with traditional programming languages (ie: CUDA C++). These are "false threads", they run in groups of 32 (NVidia) or 64 (AMD) and have unique characteristics compared to traditional threads.

2. The push for "Task-based" parallelism. Instead of writing threads, you should write tasks. Tasks are then run on a thread-pool. The difference being: Tasks don't always spin up a new thread. You track "dependencies" between tasks to minimize communication and synchronization instead. Tasks are both more efficient than threads AND easier to reason about. The crazy example is Intel's "Inefficient Fibonacci": https://software.intel.com/en-us/node/506102 . The task-based Fibonacci is both efficient and simple. Threads simply cannot compete.

-------------------

It turns out that threads themselves are both inefficient and complex. Pure performance pushes us towards SIMD / GPGPU compute. Even on CPUs, the fastest computational model is AVX or AVX512.

Simplicity pushes us towards the Tasking model, which happens to be more efficient in practice anyway. Its far cheaper for thread-pools to swap tasks, rather than spinning up threads for the scheduler to pass around and manage.

Classical thread based programming seems like a dead end to me. Its too complex and doesn't give enough returns on modern architectures. The Task model is built on top of threads, but I expect most programmers to switch to the Tasking model, and only to leave "Threads" to the OS-devs or System-level devs far below.

The SIMD model gets everything done efficiently with barriers in most cases (no need for semaphores or mutexes... indeed... mutexes don't work on traditional SIMD GPUs like Pascal or AMD Vega... due to how SIMD Wavefronts execute). Other issues are handled with "CUDA Shared Memory" or "OpenCL Local Memory" and atomics. Its weird to lose the Mutex or Semaphore as a tool, but you learn that you really didn't need it once you learn to use Barriers and Atomics effectively.

SIMD Model gets a LOT done with atomics, popcount, ballot, and various primitives that are alien to CPU Programmers. Watch a "Merge Path based Parallel Merge Sort" on a GPU if you wanna see what I mean. Its very alien, but it works extremely efficiently.

Tasks similarly have a different model compared to Threads. They're the natural successor. Almost everything I can think of can be more elegantly expressed as a Task instead of as a Thread. That'd be OpenMP 4.0, Intel TBB, or Microsoft PPL.

agumonkey3• 7 years ago

I now understand the appeal of clojure (or FP concurrency):

- can't mutate

- except for automatically synchronized entities

have fun

Threads Basics (2009)

Related Stories