Coordination Data Structures Overview

re: Coordination Data Structures Overview

Steffen Zeidler — Fri, 20 Jun 2008 10:29:56 GMT

The call CountdownEvent.Wait() can block the scheduler, is this correct?

For example on a task manager with 2 processors and 2 threads per processor if there are 4 CountdownEvent waiting and then no more tasks can start.

var event1 = new CountdownEvent(1);

Parallel.For(0, 8, i => { Debug.WriteLine(i); event1.Wait(); });

//2 3 0 1

The behaviour is the same using BlockingCollection.Remove().

There is no such behaviour using Future.Wait().

var event1 = Future<bool>.Create();

Parallel.For(0, 8, i => { Debug.WriteLine(i); event1.Wait(); });

//1 0 3 2 4 5 7 6

re: Coordination Data Structures Overview

Alexandre — Sat, 21 Jun 2008 00:09:55 GMT

This looks more and more interesting.

I have been following this blog for a little while, and I have had a question in mind since then, which I have not seen addressed, and which I do not really know where to post:

Is there any plan for PFX to use the GPU (graphics processor) incredible parallel processing abilities to accelerate Parallel.NET routines?

re: Coordination Data Structures Overview

toub — Mon, 23 Jun 2008 18:09:00 GMT

Steffen, with the current CTP, yes, you can end up blocking all of the scheduler's threads, but the situation will improve with future releases; the current implementation is missing some features that causes the behavior you're seeing.

re: Coordination Data Structures Overview

toub — Mon, 23 Jun 2008 18:18:44 GMT

Alexandre, we're certainly investigating general purpose GPU support, but we don't have anything to discuss regarding it at this time.

re: Coordination Data Structures Overview

Art Scott — Fri, 04 Jul 2008 03:39:59 GMT

Hi Stephen. Thanks for the blog.

I like Edward Lee's paper, is that MS's direction?

The Problem with Threads, by Edward A. Lee

EECS Department, University of California, Berkeley

http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

Threads are a seemingly straightforward adaptation of the dominant sequential model of computation to concurrent systems... in software in order to take advantage of the predicted increases in parallelism ... I argue that this is not a good idea. They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism. Rather than pruning nondeterminism, we should build from essentially deterministic, composable components. The consequences of this principle are profound. I argue for the development of concurrent coordination languages based on sound, composable formalisms.

re: Coordination Data Structures Overview

Art Scott — Fri, 04 Jul 2008 04:32:18 GMT

I concur with the concerns expressed about graphics concurrent parallel performance benefiting from multi-core-CPU-GPGPU HW systems improvements.

I'd like to know more about the uniqueness, specialness of the UI thread in a multi-core world.

Thanks

re: Coordination Data Structures Overview

Chernichkin Stanislav — Thu, 24 Jul 2008 20:04:10 GMT

It would be nice if heap-based collection or any other type of priority-queue will be introduced in standard library.

re: Coordination Data Structures Overview

Rick Hudson — Fri, 25 Jul 2008 17:59:17 GMT

"They impalement IConcurrentCollection<T>, a new interface providing thread-safe Add and Remove ..."

Impalement seems a bit strong for such a useful interface.

- Rick

Netmedia » Blog Archive » C# 3.0 and Parallel FX/LINQ in Mono

Netmedia » Blog Archive » C# 3.0 and Parallel FX/LINQ in Mono — Tue, 29 Jul 2008 16:40:17 GMT

PingBack from http://blog.netmedia.info/index.php/2008/07/29/c-30-and-parallel-fxlinq-in-mono/

re: Coordination Data Structures Overview

Frank Bakker — Mon, 08 Sep 2008 22:07:53 GMT

I really like the idea behind the LazyInit<T> class you added to the June CTP. I would like to give my feedback on the scenario's where I would like to use it that I think are not fully supported

T is not allowed to be a value type, this prevents me from using it for calculations returning integers or decimals that are quite common in financial scenario's.

Moreover the ValueSelector is not allowed to return null. In some of cases however null can be a valid value for a field an doesn't have to mean 'has not been initialized yet.

I would opt to throw in the extra _isInitialized boolean to allow for both value types and refrence types that may be null, that would make this a real usefull feature..

Besides that I was thinking about the way I would use this LazyInit object in a class like the following:

class person

{

string FirstName { get; set; }

string LastName { get; set; }

string WholeName { get { return FirstName + LastName);} }

}

I would like to cache the value of WholeName (being an expensive calculation), and do something like:

class person

{

string FirstName { get; set; }

string LastName { get; set; }

LazyInit<string> _wholeName = new LazyInit<string>(() => FirstName + LastName);

string Wholename { get { return _wholeName.Value; } }

}

Unfortunately it is not allowed by the compiler to reference other fields inside the lambda that is used in de field initializer and I would have to create the LazyInit object in the constructor (introducing more code). An alternative approach could be:

class person

{

string FirstName { get; set; }

string LastName { get; set; }

LazyInit<string> _wholeName = new LazyInit<string>();

string Wholename { get { return _wholeName.Retreive(() => FirstName + LastName);}

}

The retrieve would look something like

T Retrieve(Func<T> valueSelector)

{

// add some smart double checking and locking here

if (!_initialized)

{

_value = valueSelector();

}

return _value;

}

The retrieve retrieves the initialized value if present, or create it if not. This allows me to write the delegate in the same context as where I want to use the result, which is generally where I want it.

Maybe I'm stretching the intended semantics for LazyInit and maybe these models should be implemented in separate types instead of mixed, but this model it would reduce the amount of code in a lot of common situations.

Parallel Programming with NET Coordination Data Structures Overview | Green Tea Fat Burner

Mon, 08 Jun 2009 05:09:07 GMT

PingBack from http://greenteafatburner.info/story.php?id=4662