6 ms·

A Modern Guide to Threads

49 points by potomak 15y ago

wtracy 15y 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 15y 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 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/ms682659(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/ms68...
- dbattaglia 15y ago
  Raymond Chen has a pretty good blog post on this: http://blogs.msdn.com/b/oldnewthing/archive/2010/08/27/10054832.aspx 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 15y ago
This is barely a guide. It just describes the problem, names some solutions but does not elaborate on those. Not too helpful really...
IgorPartola 15y 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#Performance http://en.wikipedia.org/wiki/Software_transactional_memory#P...
- obtu 15y 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.
  - IgorPartola 15y 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.
    - rsanders 15y ago
      What about JavaScript makes it inherently single-threaded? I would describe it as more of a counter-example. There's nothing preventing a multi-threaded JavaScript except for the implementor's choice to avoid it. When the need for parallel computation became strong enough, Web Workers were created with a shared-nothing, message-passing design. I'm no fan of GILs, but I've been burned enough times with explicit locking that I respect any attempt to find a Third Way. And why provide a lock facility if the third way is a truly usable alternative?

49 points by potomak 15y 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 15y 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 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/ms682659(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/ms68...
dbattaglia 15y ago
Raymond Chen has a pretty good blog post on this: http://blogs.msdn.com/b/oldnewthing/archive/2010/08/27/10054832.aspx 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 15y ago

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

IgorPartola 15y 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#Performance http://en.wikipedia.org/wiki/Software_transactional_memory#P...

obtu 15y 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.
- IgorPartola 15y 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.
  - rsanders 15y ago
    What about JavaScript makes it inherently single-threaded? I would describe it as more of a counter-example. There's nothing preventing a multi-threaded JavaScript except for the implementor's choice to avoid it. When the need for parallel computation became strong enough, Web Workers were created with a shared-nothing, message-passing design. I'm no fan of GILs, but I've been burned enough times with explicit locking that I respect any attempt to find a Third Way. And why provide a lock facility if the third way is a truly usable alternative?