Front page | perl.perl6.language |
Postings from May 2010
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.Thread Previous | Thread Next