From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5e33596f6e327984bcba73a0386dfd83@quanstro.net> From: erik quanstrom Date: Thu, 31 Jul 2008 10:01:29 -0400 To: leimy2k@gmail.com, 9fans@9fans.net MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [9fans] Plan 9 on Blue Gene Topicbox-Message-UUID: f8336aa6-ead3-11e9-9d60-3106f5b1d025 > I've been writing a lot of Erlang code lately, and I keep thinking about, > but not having too much time to do much about, wanting to have a runtime for > the libthread "threads" that could auto-schedule them to libthread "procs", > in much the same way Haskell "sparks" may end up real threads, or Erlang > processes, might run in parallel. the model is that there may be any number of procs sharing memory, channels, etc. each proc has at least one thread. threads have their own stack and one one-at-a time. since threads run one at a time and have a few, well-known calls that implicitly schedule, one often needs no locking. this is like the big kernel lock in linux. and so in general converting threadcreate to proccreate will break programs which rely on the implicit mutex between threads to keep memory accesses from overlapping. my personal and uninformed opinion is that it's better to be explicit about resource sharing and just lock critical sections—or better yet, don't overlap data use. use channels to transfer data. if there's no overlapping data access then proccreate and threadcreate may usually be interchangable. another personal opinion is that parallelism can be a "performance hack". however, when the speed differences between various resources (e.g. disk drive seek vs anything else) is great enough, the difference between working and broken can be parallelism. - erik