On Aug 31, 2010, at 4:24 PM, Brad Roberts wrote:

> On Tue, 31 Aug 2010, Sean Kelly wrote:
>> 
>> Theoretical mumbo-jumbo, mostly.  Here's the wiki entry: http://en.wikipedia.org/wiki/Spurious_wakeup  For the most part, it's just good programming practice to double-check the invariant on wakeup.
> 
> Very much not theoretical.  I've seen it happen more than a little.  A lot of it can be blamed on using notify all rather than notify one type behavior.  The other ways it can happen is signals for things like gc pause/resume, or pipe, or ... breaking in-progress sleeps.

Oops, for some reason I thought pthread_cont_wait would return EINTR for most of those cases, but that's semaphore_wait.  You're right, a signal, etc, could cause the condition wait call to return and we can't detect this inside the Condition object.  I've seen the signals used for gc cycles cause all sorts of blocking calls to return in D, so that's a very real issue regardless how good one might consider the rest of the logic in their code.  For conditions, using a loop is so automatic that I've never seen the issue there.  Interesting that the quotes from D. Butenhof would be so off-base.  I guess he was simply talking about the wait algorithm itself rather than the interaction of conditions with other stuff.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100831/831ebf79/attachment.html>

An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100831/229b26c8/attachment.html>

An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100831/05645d01/attachment.html>

  On 8/31/2010 3:07 PM, Sean Kelly wrote:
> A few general comments:
>
> I'm wondering whether the use of a TaskPool should always be explicit.  Perhaps a default pool should be considered to exist, and calling parallel() instead of pool.parallel() will use that?  It's rare for apps to have multiple distinct pools anyway, so this may be an easy way to help obscure a tiny bit more of the implementation.

Ok, I've done the following:

1.  There is now a default pool that is initialized lazily with the default number of threads.  The function that retrieves it is called taskPool().

2.  Just to save typing and make the API a little more elegant, I added a free function parallel() as a synonym for taskPool.parallel().

3.  I don't want to make map() and reduce() free functions that forward to taskPool.map() and taskPool.reduce() because these would collide with std.algorithm which I expect would also be imported in most modules using std.parallelism.  This would force use of qualified names and not actually be any less verbose than just typing taskPool.map().  I could make parallelMap() and parallelReduce() functions, but these are not any less verbose.

4.  For tasks, I added a little syntactic sugar:

// Submit to default pool.
auto myTask = task!myFun(args).submit();

// Submit to explicitly instantiated pool.
auto pool = new TaskPool();
auto myTask = task!myFun(args).submitTo(pool);

Unfortunately, core.cpuid is still kind of buggy, so on a lot of newer Intel machines the default pool will have the wrong number of threads until this gets fixed.  If anyone can think of a decent API, I can make the number of threads in the default pool configurable.

  On 8/31/2010 11:33 PM, David Simcha wrote:
> Unfortunately, core.cpuid is still kind of buggy, so on a lot of newer Intel machines the default pool will have the wrong number of threads until this gets fixed.  If anyone can think of a decent API, I can make the number of threads in the default pool configurable.

Never mind, I ended up just defining global getter and setter functions for this.  The value is initially set via a static this() statement to coresPerCPU - 1, so if it's never set, that's the default.

  On 8/31/2010 3:07 PM, Sean Kelly wrote:
> Ideally, the syntax for map() and reduce() should match std.algorithm.  Not sure what this means for blockSize though.  Maybe it should be a template parameter?
>

Oh wait a minute, right, mine didn't support multiple functions like std.algorithm.  Anyhow, I've fixed this so multiple functions are now supported.

I'll post a few comments to digitalmars.d.

Andrei

On 8/29/10 12:56 PM, David Simcha wrote:
> Since there seems to be interest in my parallelfuture library becoming std.parallelism even if it uses unchecked implicit sharing, I've cleaned up the code, removed anything that could possibly be construed as having been borrowed from Tango (which previously was just a few tiny, unoriginal ASM snippets) and improved the documentation. I'm requesting review of it. The code is available at:
>
> http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d
>
>
> A draft of how the documentation would look is available at:
>
> http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html
>
> BTW, how are we working the review process for new modules? Do they get reviewed here first, then in the NG, should they be posted directly to the NG, or what?
>
> --Dave
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos