[phobos] std.parallelism: Request for review/comment
sean at invisibleduck.org
Tue Aug 31 13:44:17 PDT 2010
On Aug 31, 2010, at 12:41 PM, David Simcha wrote:
> On Tue, Aug 31, 2010 at 3:07 PM, Sean Kelly <sean at invisibleduck.org> 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.
> I could create a default lazily initialized Singleton for the TaskPool (a few other people I've showed this code to have requested this, too, so maybe it's a trend), but I absolutely insist on being able to manually initialize it. First of all, this gives the user the ability to manually decide how many threads to use. Secondly, I've had use cases where all threads in a pool are blocked waiting for the same really expensive computation to complete, so I fire up a new pool to do that really expensive computation in parallel.
Right. I've added some fancy behavior to the TaskPool itself so the thread count is a bit more dynamic, but that tends to overcomplicate the code. Your approach is probably better.
> Rather than making the use of 'break' inside parallel foreach undefined, why not say that it aborts the processing of the current block?
> When waiting on condition variables, there's a remote chance that wait() will return when there isn't actually something to process. Instead of:
> if (!condition)
> while (!condition)
> I saw the "if" approach in "AbstractTask* pop()"... I think that's the only one.
> Thanks, will do. How does this happen, though?
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.
> In "ReturnType spinWait()" you throw "exception" if it exists but don't clear the variable. Will this be a problem?
> I can't see why it would be a problem. Also, if for some crazy reason the user handles the exception and then tries to get at the return value again, IMHO the correct behavior is to throw it again. If there's something I'm missing, please let me know.
I hadn't spent enough time with the code to know what the correct behavior should be, so I asked.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the phobos