A Modern Guide to Threads

Re:A Modern Guide to Threads by IgorPartola on Friday December 02, 2011 @09:46AM (#3304112)

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.

[ Parent | on HN ]

Re:A Modern Guide to Threads by rsanders on Friday December 02, 2011 @09:53PM (#3306742)

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?

[ Parent | on HN ]

Re:A Modern Guide to Threads by IgorPartola on Saturday December 03, 2011 @08:07AM (#3307653)

Implementer's choice is the only reason. What I am saying is that since the implementer chose to make it single-threaded, they should choose not to include unnecessary locking facilities.

While locking can sometimes be a pain to reason about (having many types of locks affecting access to one piece of data, etc.), on a lot of situations they are very useful. The GIL is exactly the opposite: easy to reason about, but rarely will it save you. Consider.

  x = cache['foo']
  y = bar(x)
  cache['foo'] = y

Here a GIL will not help here: while lines 1 and 3 are atomic and the call to bar() may or may not be atomic, there is no guarantee that the whole set of operations is atomic. Thus you need an explicit locking mechanism. A GIL is a pattern that makes implementation of interpreters simple. It does not help in problems where you may be burned by locks.

[ Parent | on HN ]