On Mon, Oct 3, 2011 at 2:25 AM, Jukka Tuominen <jukka.tuomi...@finndesign.fi> wrote: > > Sorry for thinking aload again, but I'm learning these issues myself in the > background, and I wonder if something like the following might work? > > Concurrent List Processing -idea > > Two phase process > > 1) Distribution phase > Create a recursive procedure combining cons and threads so that each item in > the original list will be replaced by a named thread. Sending out new threads > won't wait for individual threads to return in this phase. The result of this > phase is a list of named threads. > > 2) Collection phase > This phase is again a recursive cons process, but this time sequential. It > starts from the beginning of the named-thread list, and as soon as the first > thread returns its value, it moves on. The process goes on until the end of > the list is reached. The resulting list is the return value.
Here's your idea, implemented with futures. I'm assuming that you want to apply a particular procedure to each element of the list, as in `map': (define (par-map f l) (define fs (for/list ([elem (in-list l)]) (future (lambda () (f elem)))) (map touch fs)) > - If the original list to be processed is very long, then the construction of > the second phase list shouldn't wait for bottle neck items to cons the list > elsewhere where possible. The speed gain wouldn't be substantial though, > since it is just building a list, and you cannot finish it until the last > item is available, anyway. You'd want to basically make the result list into a queue in which elements are inserted. -- sam th sa...@ccs.neu.edu _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
