Threads are the wrong kind of abstraction

Threads are a bad abstraction for a number of reasons. Much like pointers, new and dispose looked so alien in Pascal!

Threads and classic multithreaded architectures have been slowly cornered by the industry as the wrong kind of abstraction. See, for instance, how Brendan Eich disses threads and promises better concurrency support for javascript using alternative abstractions. His basic problems with threads:

  • They create race conditions
  • They create deadlock hazards
  • Even when nothing fails, they create pessimistic locking overhead
  • And still they don’t scale up to handle the megacore teraflop future.

I have been thinking about a good metaphor to compare threads as a bad abstraction with. Today I got the idea of comparing it with Pascal typed pointers. Not high level enough, not performant enough. And the programmer was required to allocate and dispose memory! Nowadays, the mere thinking of a language that is supposed to be high level having pointers looks silly to me, but at the time pointers were needed because abstract data types were not good enough. I was coming to Pascal from Lisp and Smalltalk, so I couldn’t understand why in life would people need to use such scary constructs, even though being type safe killed half of the problem.

Similarly I guess in the future programmers will call us crazy because we exposed threads to user side programmers.

Note: Following Brendan entry to Tamarin, base for the concurrency-aware JS4, I notice that I forgot to mention the Mozilla foundation in the Mercurial field in my post about Source Code Managers. This balances its user base somehow better: git has freedesktop + linux kernel versus mozilla + java in mercurial, but I still bet git+bazaar for smallish projects as winners in this competition.

Add your comment












Nav Bar