Re: Implicit threading vs Imperative barriers
On Thu, Jun 4, 2009 at 9:57 AM, TSa wrote: > HaloO, > > Daniel Ruoso wrote: >> >> So the questions are: >> >> * Are there any imperative barriers in Perl 6? > > I would think that at least every method call is a barrier. > An object's lifetime is a sequence of states and methods are either > returning information about the state or calculate a new state. The > latter cannot be concurrent. Furthermore it is usually a bad idea > to have an object in several concurrent computations such that > streams of mutating method calls interleave. So objects destined > for parallel computing need some explicit locking mechanism. Perhaps it isn't the method call that's the barrier, but rather the mutating function. If you do nothing but call a series of non-mutating methods, I don't see how it matters how quickly any given one of them gets evaluated, or even in what order they're evaluated, as long as the information is ready by the time you need it. But as soon as you call a mutating method, you'd better get all of those pending non-mutating calls taken care of before you proceed with the mutating call. Rule of thumb: if you want to be lazy, look but don't touch. -- Jonathan "Dataweaver" Lang
Re: Implicit threading vs Imperative barriers
HaloO, Daniel Ruoso wrote: So the questions are: * Are there any imperative barriers in Perl 6? I would think that at least every method call is a barrier. An object's lifetime is a sequence of states and methods are either returning information about the state or calculate a new state. The latter cannot be concurrent. Furthermore it is usually a bad idea to have an object in several concurrent computations such that streams of mutating method calls interleave. So objects destined for parallel computing need some explicit locking mechanism. * Does that mean we need to spec a common way of implementing implicit-threading and implicit event-based programming? I doubt that implicit threading is feasible in an imperative language like Perl. Lazy lists are comparatively easy because they are sequential values produced by a single closure. But a lazy object has a lot of methods that can be invoked in complicated patterns. So there must be explicit locking or continuation mechanisms that allow the programmer to stall certain calls or to enforce the completion of dependent threads. I can envision a lazy object's state to branch whenever a method doesn't run to completion. So a single object becomes an overlay of different states of execution that eventually collapse to a state of interest or are never realized. This non-realization of expensive state calculations is the benefit of lazy objects but the branching of the states is a heavy burden. In summary I believe it doesn't pay off. IOW, objects are best kept eager. Regards TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
