A Modern Guide to Threads

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 ]