Concurrency Models

Andrew Whitworth wknight8111 at gmail.com
Tue Jul 13 21:22:15 UTC 2010


On Tue, Jul 13, 2010 at 4:26 PM, chromatic <chromatic at wgz.org> wrote:
> 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.

I agree, lighter-weight interpreter objects would be nice. Chandon was
talking about paring them down to be more light-weight, but I'll let
him share the details of his plan once it's ready.

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

Agreed. The common case will likely be single-threaded systems, or
systems which only use green threads, so data sharing becomes a very
small issue. In these situations, we don't want to see a huge overhead
tax placed on all accesses, since we don't need it. Some system which
lazily applies synchronization mechanisms only when required would be
nice (though probably difficult to implement)

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

This seems like an argument that every shared PMC must be explicitly
shared/synchronized or else it cannot be used in separate threads.
That is, we would rather prefer no access to unsafe access.

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

I definitely don't think we want a huge angry GIL, but having a lock
for write operations on global data (namespaces and the class cache
come to mind) might be nice. I'm not sure how we can redo things to
avoid locking these global items.

> 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.

I agree with that too, though we end up placing much more burden on
the extension developers. If we go this route, we're going to have to
spend much more effort to make sure the concurrency portions of our
extension API is very sane and very useable.

--Andrew Whitworth


More information about the parrot-dev mailing list