Concurrency Models

chromatic chromatic at wgz.org
Tue Jul 13 20:26:30 UTC 2010


On Tuesday 13 July 2010 at 13:08, Andrew Whitworth wrote:

> My question to the larger parrot community is this: Assuming that in a
> month we have a more-or-less working and usable threading
> implementation in Parrot, how do we want to handle sharing of data?

My preference is a message passing system with lightweight interpreters and 
some sort of PMC proxy to coordinate data which must appear shared between 
threads/processes.

Whatever we do, we need to attempt to meet a few goals:

* low CPU overhead for creating/managing concurrent entities of execution 
(avoid the cost of creating a new Perl 5 interpreter, for example)

* share as little as possible and that only explicitly (to avoid the C problem 
of thread-unsafety by default)

* allow options for parallelism and concurrency (to permit building something 
like Python's GIL or Perl 5's ithreads without dictating too much)

If possible, it'd be nice to avoid the problem that many dynamic languages run 
into with C extensions, where wrapping a library that's not thread safe 
dictates that the entire extension system needs a global lock.

-- c


More information about the parrot-dev mailing list