www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Parallel ranges, how?

reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
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 22 2010
parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
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
next sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
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
parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
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
May 30 2010
prev sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
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
parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
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