Thread overview
Parallel ranges, how?
May 22, 2010
Simen kjaeraas
May 30, 2010
Simen kjaeraas
May 30, 2010
Philippe Sigaud
May 30, 2010
Simen kjaeraas
May 30, 2010
Philippe Sigaud
May 30, 2010
Simen kjaeraas
May 22, 2010
How does the current range system accommodate parallel iteration?

As far as I can see, a context switch could happen between calls to
popFront and front, thus popping a value off the range before we're
able to get its value.

-- 
Simen
May 30, 2010
Simen kjaeraas <simen.kjaras@gmail.com> wrote:

> How does the current range system accommodate parallel iteration?
>
> As far as I can see, a context switch could happen between calls to
> popFront and front, thus popping a value off the range before we're
> able to get its value.

Anyone? It seems to me the system is not thread-safe, and a parallel
range should have the functions lock() and unlock(), so a foreach
would work basically like this:

foreach( e; r ) {
  stuff(e);
}
=>
while(true) {
    r.lock();
    if (r.empty) {
        unlock();
        break;
    }
    auto e = r.front;
    r.popFront();
    r.unlock();

    stuff(e);
}

Note that this approach does not in any way protect access to the
elements, only the range functions.

-- 
Simen
May 30, 2010
On Sun, May 30, 2010 at 22:59, Simen kjaeraas <simen.kjaras@gmail.com>wrote:

> Simen kjaeraas <simen.kjaras@gmail.com> wrote:
>
>  How does the current range system accommodate parallel iteration?
>>
>> As far as I can see, a context switch could happen between calls to popFront and front, thus popping a value off the range before we're able to get its value.
>>
>
> Anyone? It seems to me the system is not thread-safe, and a parallel
> range should have the functions lock() and unlock(), so a foreach
> would work basically like this:
>

I don't know if that'd help you, but did you have a look at David Simcha's parallelFuture module?

http://cis.jhu.edu/~dsimcha/parallelFuture.html


May 30, 2010
I don't know if that'd help you, but did you have a look at David Simcha's parallelFuture module?

>
> http://cis.jhu.edu/~dsimcha/parallelFuture.html<http://cis.jhu.edu/%7Edsimcha/parallelFuture.html>
>
>

Gosh, dsimcha just made a post on it in the Phobos mailing list.That's what I'd call parallel and concurrent :-)


May 30, 2010
Philippe Sigaud <philippe.sigaud@gmail.com> wrote:

> I don't know if that'd help you, but did you have a look at David Simcha's
> parallelFuture module?
>
>>
>> http://cis.jhu.edu/~dsimcha/parallelFuture.html<http://cis.jhu.edu/%7Edsimcha/parallelFuture.html>
>>
>>
>
> Gosh, dsimcha just made a post on it in the Phobos mailing list.That's what
> I'd call parallel and concurrent :-)

Yeah, I noticed as well. Got the message right after my post here. :p

-- 
Simen
May 30, 2010
Philippe Sigaud <philippe.sigaud@gmail.com> wrote:
> I don't know if that'd help you, but did you have a look at David Simcha's
> parallelFuture module?
>
> http://cis.jhu.edu/~dsimcha/parallelFuture.html

Looked at it now. It's not exactly what I was thinking.
parallelFuture foes the foreach in one thread, and work in others,
whereas my problem is that of iterating over the thread in two or
more thread simultaneously, while giving each thread a unique
selection of items. Not entirely sure this is a good way to do it,
but it certainly is *a* way, and it may have its uses.

-- 
Simen