INTERESTING? Any interest in a Task Parallel Library (multithreading) Package?

I wrote a multithreading framework very similar to the .net 4.0 Task Parallel Library (TPL), and want to know if there is any interest in this.

more info:
The TPL is not available in .net 2.0, and thus not available in mono, so this is for developers who want a “real” multithread library instead of the coroutines (yield) pattern that unity supports by default.

my implementation is not the exact same as the TPL, mostly as I don’t provide PLINQ. But I do provide parallel for/foreach, thread safe data structures, and improvements beyond the default ThreadPool

so, in summary:
if you desperately wish for multithread library improvements, let me know by replying to this thread, and I can get this working in unity quickly. (it already is running in mono)

if you think this is a waste of time, please let me know that too! :stuck_out_tongue:

Hi Jason!

I think that the idea is very interesting.
Just my two cents :slight_smile:

Kenshin

will it work on mobile?

If you’re going to provide a real, tested, API compatible version of TPL, even without plinq. Count me in as a purchasser at 100$. if you manage to also add rx framework you can even do 150+
However it should be a simple dll with no workaround to implement. Just dl asset and access the aditional api. And i’m not purchasIng outside of the asset store so it would have to be on there

Now I’m not much for multi-threading (haven’t really used it much) but This would actually be a good way to load up stuff in some of the apps I’m working on.

I’d buy this if it is tested and simple enough. Anywhere from $100-200

okay thanks for the feedback guys, it sound’s like there’s interest, so I’ll make it happen. We just started our first unity game, so I don’t have any experience with creating packages (yet) so I’ll start off by getting my TPL working in unity, then put together the package…

fyi, I used this as a core part of my studio’s old (xna based) engine, and have it fully tested. (and i’ll be sure to include stress tests so you can verify)

also, sorry no rx support. mostly because I haven’t used it so haven’t thought of how to get it working in .net2

do you need it to be API compatible (or near)? my API is functionally compatible but isn’t a clone. (I wrote it’s v1 before TPL was announced, and thus the design isn’t exact) After TPL was announced I updated my API with some of TPL’s design patterns, but I didn’t worry about cloning the api.

Here’s an example of what my framework can do for parallel foreach

//create a normal List<int>
var myList = new List<int>();
//add 1000 ints
for(int i=0;i<1000;i++)
{
	myList.Add(i);
}

//new thread-safe collection included in my framework
var safeQueue = new Ngs.Collections.Concurrent.SafeQueue<int>();

//loop the List<int> in parallel and add to the queue
myList.ParallelForEach((x) => safeQueue.Enqueue(x + 1) );

//dequeue all existing (1000) and re-enqueue to the same collection 1000 more (in-parallel!)
safeQueue.ParallelDequeue((x) => safeQueue.Enqueue(x - 1));

//non-threaded test to verify integritry
Debug.Assert(safeQueue.Count == myList.Count);
int y;
while (safeQueue.TryDequeue(out y))
{
	Debug.Assert(myList.Contains(y));
	myList.Remove(y);
}
Debug.Assert(safeQueue.Count == 0);
Debug.Assert(myList.Count == 0);

yes it works on mobile, but on systems with only 1 cpu you won’t see much (any) benefit except for things that have blocking calls (like network or disk IO)

I would really lIke API compatibility. The additional work of doing that is probably paid off by redirecting to msdn for documentation instead of rolling your own too. Personally i don’t care about parallel.foreach but about the Task API and it being API compatible is a major plus

could you give me a list of “most important” classes / functionality you’d need? Obviously Task, but I’d like to hear what else.

Really mostly all the functionality of the Task API is fine, i don’t really care for the other branches (except for plinq but i can live without that since you said it’s not included, and that doesn’t sound like something hard to port anyway if i really feel the need).
So pretty much every function available on Task could prove of use, so everything allowing to chain / compose tasks at least (all continues and waits etc)

I have a few points:

  • I’ve greatly appreciated the .NET 4.5 simplicity of
    Task.Run(Func function)
    Task.Run(Action action)
    The syntax is way cleaner than the .Net 4.0 equivalents
    Task.Factory.StartNew(Func function)
    Task.Factory.StartNew(Action action)

  • Ensuring that the Task is complete before the get accessor returns for the property
    Task.Result

  • For the situations where the Producer-Consumer pattern comes into play (starting 2 threads, one to make objects, and one to consume them), the .Net 4 class BlockingCollection is very handy. It “provides blocking and bounding capabilities for thread-safe collections.”