Comments on: OSCON 2007 http://www.sauria.com/blog/2007/08/03/oscon-2007/ Open Source, Modern Programming Languages, OS X, Photography, and ... Thu, 19 Jan 2012 07:08:30 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Ted Leung http://www.sauria.com/blog/2007/08/03/oscon-2007/comment-page-1/#comment-6320 Ted Leung Thu, 09 Aug 2007 20:32:59 +0000 http://www.sauria.com/blog/2007/08/03/oscon-2007/#comment-6320 Kevin, Threads are to concurrency what malloc/free are to memory management. Additional refs: http://www.knowing.net/PermaLink,guid,753006f4-48d0-4afe-ae1c-a96d96875cf8.aspx http://www.tbray.org/ongoing/When/200x/2007/02/08/Berkeley-Parallel http://lambda-the-ultimate.org/node/2386 Doug The orginal work on Actors is much earlier than Erlang: http://en.wikipedia.org/wiki/Actor_model Kevin,

Threads are to concurrency what malloc/free are to memory management.

Additional refs:
http://www.knowing.net/PermaLink,guid,753006f4-48d0-4afe-ae1c-a96d96875cf8.aspx
http://www.tbray.org/ongoing/When/200x/2007/02/08/Berkeley-Parallel
http://lambda-the-ultimate.org/node/2386

Doug
The orginal work on Actors is much earlier than Erlang:
http://en.wikipedia.org/wiki/Actor_model

]]> By: Doug L. http://www.sauria.com/blog/2007/08/03/oscon-2007/comment-page-1/#comment-6319 Doug L. Thu, 09 Aug 2007 19:19:13 +0000 http://www.sauria.com/blog/2007/08/03/oscon-2007/#comment-6319 Kevin, there are two directions that appear to lead to much more maintainable and debuggable concurrent code than shared-state threads do. One (which Ted mentioned) is <a href="http://en.wikipedia.org/wiki/Software_transactional_memory" rel="nofollow">STM (Software Transactional Memory)</a> (decent wikipedia summary); SPJ wrote or co-wrote <a href="http://research.microsoft.com/%7Esimonpj/papers/stm" rel="nofollow">some excellent papers</a> about STM in Haskell. The other is Erlang-style actors/processes, either native <a href="http://en.wikipedia.org/wiki/Erlang_programming_language" rel="nofollow">in Erlang itself</a>, or via the actors library in the Scala language, a particularly interesting implementation of a variant of the Erlang approach. For the latter, see the papers "Actors that Unify Threads and Events" or "Event-Based Programming without Inversion of Control" at <a href="http://www.scala-lang.org/docu/papers.html" rel="nofollow">the Scala docs page</a>, or <a href="http://lamp.epfl.ch/~phaller/doc/ActorsTutorial.html" rel="nofollow">Philipp Haller</a>'s simple html-based Actors tutorial. Kevin, there are two directions that appear to lead to much more maintainable
and debuggable concurrent code than shared-state threads do. One (which Ted
mentioned) is STM (Software
Transactional Memory) (decent wikipedia summary); SPJ wrote or co-wrote some excellent
papers about STM in Haskell.

The other is Erlang-style actors/processes, either native in Erlang
itself, or via the actors library in the Scala language, a particularly
interesting implementation of a variant of the Erlang approach. For the
latter, see the papers “Actors that Unify Threads and Events” or “Event-Based
Programming without Inversion of Control” at the Scala docs page, or
Philipp
Haller‘s simple html-based Actors tutorial.

]]> By: Kevin Farnham http://www.sauria.com/blog/2007/08/03/oscon-2007/comment-page-1/#comment-6317 Kevin Farnham Wed, 08 Aug 2007 14:50:13 +0000 http://www.sauria.com/blog/2007/08/03/oscon-2007/#comment-6317 I'm interested in your statement that you do not believe that "threads are the right abstraction for concurrent programming." Have you written in greater detail about this elsewhere, or can you point me to some articles or blog posts by others on this topic? I’m interested in your statement that you do not believe that “threads are the right abstraction for concurrent programming.” Have you written in greater detail about this elsewhere, or can you point me to some articles or blog posts by others on this topic?

]]>