From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3e1162e60807310728o4cf78211ud5ad698d252f972b@mail.gmail.com> Date: Thu, 31 Jul 2008 07:28:14 -0700 From: "David Leimbach" To: "erik quanstrom" In-Reply-To: <2049e07e918215a675b00f15ee549436@quanstro.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_89683_20938367.1217514494744" References: <2049e07e918215a675b00f15ee549436@quanstro.net> Cc: 9fans@9fans.net Subject: Re: [9fans] Plan 9 on Blue Gene Topicbox-Message-UUID: f8475430-ead3-11e9-9d60-3106f5b1d025 ------=_Part_89683_20938367.1217514494744 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, Jul 31, 2008 at 7:01 AM, erik quanstrom wrot= e: > > I've been writing a lot of Erlang code lately, and I keep thinking abou= t, > > but not having too much time to do much about, wanting to have a runtim= e > 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 Erlan= g > > 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. Channels are locked though right, implicitly, such that they can be used as a "safe" communication mechanism between proccreate'd contexts and threadcreate'd contexts in a safe way. Therefore, if you're not sharing memory between threads/procs, the model holds up just fine for the CSP style concurrency it was intended to implement. Basically "don't share", and "just do message passing". Obviously depending on the C calls involved, some are re-entrant and some are not, and that makes a rather large difference too. You don't want to call strtok from two different threads (unless you have thread local storag= e available, then it might be safe). > > > my personal and uninformed opinion is that it's better to be explicit > about resource sharing and just lock critical sections=97or 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. This is exactly what I'm referring to. > > > 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. I think if you take the definition of concurrent processes, that is any set of processes with no defined sequence or ordering to them running, and you have them cooperating to produce a solution AND they can run at the same time, you're talking about a form of parallelism. For many people, designing code that's concurrent is enough to express the solution in a san= e way, without tracking mutexes and locks and shared resources, and parallelism is just "icing". For some "pure parallelism" is the end goal. And there's often a very different approach to getting that (OpenMP, Parallel Haskell vs Concurrent Haskell. Erlang running with SMP enabled.) Dave > > > - erik > ------=_Part_89683_20938367.1217514494744 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline


On Thu, Jul 31, 2008 at= 7:01 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> I've been writing a lot of Erlang code latel= y, and I keep thinking about,
> but not having too much time to do much about, wanting to have a runti= me for
> the libthread "threads" that could auto-schedule them to lib= thread "procs",
> in much the same way Haskell "sparks" may end up real thread= s, 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.
=
Channels are locked though right, implicitly, such that= they can be used as a "safe" communication mechanism between pro= ccreate'd contexts and threadcreate'd contexts in a safe way. =

Therefore, if you're not sharing memory between thr= eads/procs, the model holds up just fine for the CSP style concurrency it w= as intended to implement.  Basically "don't share", and = "just do message passing".

Obviously depending on the C calls involved, some are r= e-entrant and some are not, and that makes a rather large difference too. &= nbsp;You don't want to call strtok from two different threads (unless y= ou have thread local storage available, then it might be safe).
 


my personal and uninformed opinion is that it's better to be explicit about resource sharing and just lock critical sections=97or better yet,
don't overlap data use.  use channels to transfer data.  if t= here's no
overlapping data access then proccreate and threadcreate may usually
be interchangable.

This is exactly what I&#= 39;m referring to.
 


- erik

------=_Part_89683_20938367.1217514494744--