After reading this thread and S17, I have lots of questions and some
remarks.
Parallelism and Concurrency could be considered to be two different things.
The hyperoperators and junctions imply, but do not require, parallelism.
It is left for the implementors to resolve whether a single or multiple
processor(s) is/are used. Hence, parallelism could be considered to be
something under the hood of perl6 and not directly specified.
Given that:
- concurrency is a topic of ongoing research
- several models of concurrency have been tried, including two in perl5
- there are a variety of contexts (internet, clouds, multiple cores, etc)
- different operating systems provide different resources
then:
How much needs to be specified and implemented in perl6 so that
different concurrency models can be implemented in modules to take into
account the above diversity?
The less, or rather the more abstract, the specification in perl6, the
less likely perl6 will 'age'.
On 05/12/2010 09:12 PM, Dave Whipp wrote:
Daniel Ruoso wrote:
Hi,
The threading model topic still needs lots of thinking, so I decided to
try out some ideas.
Every concurrency model has its advantages and drawbacks, I've been
wondering about this ideas for a while now and I think I finally have a
sketch. My primary concerns were:
1 - It can't require locking: Locking is just not scalable;
2 - It should perform better with lots of cores even if it suffers
when you have only a few;
3 - It shouldn't require complicated memory management techniques
that will make it difficult to bind native libraries (yes, STM
is damn hard);
4 - It should suport implicit threading and implicit event-based
programming (i.e. the feed operator);
5 - It must be easier to use then Perl 5 shared variables;
6 - It can't use a Global Interpreter Lock (that already said in 1,
but, as this is a widely accepted idea in some other environments,
I thought it would be better to make it explicit).
The idea I started was that every object has an "owner" thread, and only
that "thread" should talk to it, and I ended up with the following,
comments are appreciated:
comments? ideas?
Before discussing the implementation, I think it's worth while stating
what it is that you are attempting to abstract. For example, is the
abstraction intended for a mapping down to a GPU (e.g. OpenCL) with a
hierarchical address space, or is it intended for a multicore CPU with
linear address space, or is it intended to abstract a LAN, with
communication via sockets (reliable TCP? unreliable UDP?), or is it
intended to abstract the internet/cloud? Are you thinking in terms of
streaming computation where throughput is dominant, or interacting
agents where latency is the critical metric?
I'm not sure that it makes sense to talk of a single abstraction that
supports all of those environments. However, there may be bunch of
abstractions that can be combined in different ways.
"object belongs to thread" can have two interpretations: one is that
the object-thread binding lasts for the life of the object; the other
is that a client that wishes to use an object must request ownership,
and wait to be granted (in some scenarios, the granting of ownership
would require the thread to migrate to the physical processor that
owns the state). In many cases, we might find that specific
object-state must live in specific "places", but not all of the state
that is encapsulated by an object lives in the same place.
Often, an object will encapsulate state that is, itself, accessed via
objects. If a model requires delegated access to owned state to be
passed through an intermediate object then this may imply significant
overhead. A better way to think about such scenarios may be that a
client would request access to a subset of methods -- and thus we have
"role belongs to thread", not "object belongs to thread". One could
imagine that a FIFO object might have a "put" role and a "get" role
that producer/consumer clients would (temporarily) own while using
(note that granting of ownership may imply arbitration, and later
forced-revocation if the resource-ownership is not released/extended
before some timeout expires). It may be wrong to conflate "role" as a
unit of reuse with "role" as an owned window onto a subset of an
object's methods.
Perl6 has a set of language primitives to support various aspects of
concurrency. It is indeed interesting to consider how these map ot
vastly difference computation platforms: OpenCl Vs OpenMP Vs Cloud. It
deeps a little premature to be defining roles (e.g. RemoteInvocation)
without defining the mapping of the core operators to these various
models of computation.
Dave.