Dream 2.0 Changes

Dependency Changes

Requires C# 3.0 & .NET 3.5

Q: should we rely on conditional compilation to support Dream 1.x and 2.x at the same time?

New Namespaces

Partition the Dream classes into new namespaces:

• MindTouch.Collections
• MindTouch.Threading

Q: other namespaces for 2.0?

Parallel .Net Collections

Should the MindTouch collections attempt to be substitutes for the System.Collections.Concurrent collections?  This would make it easier for these collections to be reused by the Mono team.

Probably not since our collections are highly specialized.

Class Naming

• LockFreeStack/LockFreeQueue: these classes are named after their algorithms and not their use.  Should they be renamed to ConcurrentStack/ConcurrentQueue? Pros/cons?
  • consider: IParallelQueue is the interface, LockFreeQueue is an implementation of the interface (alternative IConcurrentConsumerProducer from .Net 4.0)
• StealingThreadPool -> WorkQueuePool?
• WorkStealingQueue -> StealingStack?
• LockFreeXmlNameTab le

Global "Ping" Event

Several mechanisms depend on regular maintenance events such as the TaskTimer and every StealingThreadPool instance.  Should there be a global "ping" event that these classes can reuse instead?  The ping callback would have the following signature:

void Ping(DateTime now, TimeSpan elapsed)

• now: UTC date time of the ping event
• elapsed: time elapsed since the last event

WorkQueue Notes

• WorkQueueThroughput: A class that throttles a work queue on work-items per second.  Requires the global ping event to calculate the number of allowed work items for the next time delta.
• StealingThreadPool: the worker threads for the pool should be taken from a global thread repository to make it easier to recycle threads across pools. (see blog post on resource management)

Coroutines

Continue improving usability of coroutines by providing an implicit stack of Result instances that can be triggered on failure.  Similarly, nested Result instances should inherit the outer time-out constraint when one is present.  Result instances should also allow for cancellation and propagate down the stack (nice to have).

Consider a function Foo as defined:

Yield Foo(int a, int b, int c, Result<int> result);

Can be invoked as follows:

Yield Bar(int x, Result result) {
    int i = 0;
    yield return Co.Invoke(Foo, a, b, c, r => i = r);
    // ...
    result.Return();
}

Which is equivalent to:

Yield Bar(int x, Result result) {
    Result<int> inner;
    yield return inner = Co.Invoke(Foo, a, b, c, new Result<int>(result.Timeout));
    if(inner.HasException) {
        result.Throw(inner.Exception);
        yield break;
    }
    int i = inner.Value;
    // ...
    result.Return();
}

Yield Bar(int x, Result result) {
    Result<int> inner;
    yield return inner = Co.Invoke(Foo, a, b, c, new Result<int>(result.Timeout)).Catch(result);
    int i = inner.Value;
    // ...
    result.Return();
}