A Modern Guide to Threads

http://blog.carbonfive.com/2011/10/11/a-modern-guide-to-threads/

by potomak • 15 years ago

49 11 15 years ago

blog.carbonfive.com

wtracy• 15 years ago

"If the main thread exits, the process dies."

This is true on Unix/Linux. I believe this is not true on Windows. (I'm not a Windows dev, so feel free to enlighten me if I am wrong.)

Everything else in the article seemed pretty OS-independent.

yread• 15 years ago

I'm not sure how is it done in Win32, but in .NET there is a IsBackground flag on a thread. Process dies when all its non-background threads exit.

http://msdn.microsoft.com/en-us/library/h339syd0.aspx

EDIT: It seems that in win32 the process does indeed die when the last thread exits. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms68...

dbattaglia• 15 years ago

Raymond Chen has a pretty good blog post on this:

http://blogs.msdn.com/b/oldnewthing/archive/2010/08/27/10054...

Basically, Win32 wants all threads to die out before the process exits, but the C runtime will exit out the process for you when your "main" thread dies.

danielatc• 15 years ago

This is barely a guide. It just describes the problem, names some solutions but does not elaborate on those. Not too helpful really...

IgorPartola4• 15 years ago

I agree with TFA: actors model is the way to go if you can swing it. However, when you are implementing the actor model, you are limited by the throughput of each actor. If the service that needs to be performed by the actor is CPU bound (say file compression), your overall throughput will also suffer. In this case a work queue and a set of workers may be more efficient.

I disagree with the statement that programming with plain threads and locks is somehow archaic. No, it is simply programming at a lower level of abstraction. In some cases it is more efficient and your specifications may require it. Think of state-heavy applications, and the interface between the module modifying internal program state (which may be done using actors or STM) and the module that performs external IO. In this case, you may need a lock to get a consistent snapshot of the data from your program's state to export it to an external source and in some cases it is more efficient to do so by locking the structure in memory.

Finally, locks don't always grow your complexity exponentially. What grows your complexity is when you have many different types of locks. Let's say we have an address book database program that implements concurrency by using threads. It is simple and inefficient to have a single global write lock. On the other end of the spectrum you have the ability to lock any field of any record, or the whole record, or a set of records, or a set of fields of a set of records, or records that don't even exist yet (gap lock) or the whole database. In-between, you have the ability to place a lock on the entire database or on just one record. You have to make the tradeoff between your time as a programmer and the efficiency of the code.

STM is a cool tool, but does have performance penalties [1]. It may be appropriate in some cases, and inappropriate at others, just like the actor model.

[1] http://en.wikipedia.org/wiki/Software_transactional_memory#P...

obtu• 15 years ago

That lower level of abstraction shouldn't be exposed in all languages, though; languages with complex instructions and garbage collection tend to be better implemented with a GIL, and it is a good idea to discourage the use of threads when these features are present. Your example of snapshotting is well addressed by forking, which eliminates the need for locks in unrelated parts of the code.

IgorPartola4• 15 years ago

Forking isn't always a good option. Imagine that your have a lot of state, and serializing it is inefficient. All of a sudden shared memory becomes a very attractive way to communicate between different modules of your program, as compared to serializing and pushing data over a pipe.

As for the GIL, while it may be convenient for organizing the codebase of the language, it is awful when it comes to using it for a heavily parallel workload. Yes, it prevents programmers from having to write code like:

  with obj.lock:
      obj.counter += 1

But it means that code that should by all means be lock free is now always blocking all threads. In other words, it helps really novice programmers write really simple single-user single use prototype-level code, but prevents concurrency in real-world production environments.

Locks should be exposed in most languages (except environments like JavaScript which are inherently single-threaded). It's just that (1) other models such as STM should be exposes as well and (2) other abstractions built on top of or related to locks (queues, events, conditions, etc). should be available as well.

regularfry• 15 years ago

Abstractions leak. By all means provide them, but don't assume that a sophisticated user won't complain if they can't get at the guts when the abstraction (or its implementation) gets in their way.

A Modern Guide to Threads

Related Stories