Interesting thread.
Two comments.
#1
Reed is correct about the TPL inlining behavior. In short, if a thread blocks, that thread is burned and won't be reused for anything else (other than normal OS level things like APCs and the like, or if a SynchronizationContext overrides the
CLR's waiting functionality, but that's very advanced and is not used by TPL). The only "caveat" to this implemented by TPL is that if that "blocking" happens by one thread Wait'ing on a Task (e.g. using Task.Wait/WaitAll/etc.), then if the task being
waited on hasn't started executing yet, it may be possible for us to run the task on the current thread ("inlining" it) rather than simply blocking for another thread to pick it up. TPL doesn't do any other kind of pumping (e.g. when waiting for one
task, it never goes back to the scheduler to say "do you have any other tasks you'd like me to run in the meantime... that's optional functionality we've considered as an opt-in kind of thing, but it doesn't exist in TPL in .NET 4 today, and it would be a
bad behavior to do automatically when blocking or waiting, leading to all kinds of reentrancy problems like the one you mention).
With regards to Parallel.For, Parallel.For itself generates some number of tasks and waits for them, so if you have a nested set of loops, e.g.
Parallel.For(0, N, i =>
{
...
Parallel.For(0, M, j =>
{
});
...
});
When the thread from the outer loop starts processing the inner parallel loop, it will almost certainly end up inlining one of the tasks generated by the Parallel.For. That way, we're able to reuse the outer thread rather than just blocking waiting
for another thread to come along to process the loop. It would be deadly for nested parallelism like this if we always blocked, as you could need a significant number of threads in the pool in order to make forward progress. This is similar to
a problem that OpenMP has with nested loops.
#2
For ConcurrentDictionary, you might consider instead of using a ConcurrentyDictionary<TKey,TValue>, using a ConcurrentDictionary<TKey,Lazy<TValue>>. Lazy<TValue> is by default thread-safe using a lock to protect the invocation
of the initializer, e.g.
public static ResamplerSet GetResamplerSet(IFull o)
{
var key = ComputeKey(o);
return resamplerSets.GetOrAdd(key, (newKey) =>
new Lazy<ResamplerSet>(() =>
new ResamplerSet(o))).Value;
}
If the key is already present, this will just return the previously initialized Lazy<> (the only additional cost you'll be paying is for the allocation of the closure object and delegate due to passing in the "o" value by closure, and you might even
be able to avoid that). If the key isn't present, then you'll initialize a new Lazy<> instance (which itself is very cheap, at least in release builds), and accessing its Value property will result in instantiating your result object. If
there's contention, multiple Lazy<> instances could get created, but again that's very cheap, and only one will end up getting published to the dictionary... then all of the threads will get the same Lazy<> instance which will provide the locking
you need to ensure that the delegate function only runs once, and all threads will return the same instance.
I hope that helps. Let me know if I misunderstood anything. Also, John, I'd be interested in knowing more about your overall usage of TPL, your experience with the library, what kinds of things you're building, what kinds of issues you're running
into, suggestions for the future, in particular considering your statement "You can see that I love the TPL, right?! :) :)" which of course warms my heart :) If you'd like to email me privately, please feel free to do so at stoub at microsoft dot com.
Thanks.
