Patrick Smacchia [MVP C#] - All Comments

famous lies

famous lies — Wed, 07 May 2008 17:43:54 GMT

Pingback from famous lies

Command-Query Separation and Immutable Builders

Matthew Podwysocki — Tue, 06 May 2008 22:24:07 GMT

In one of my previous posts about Command-Query Separation (CQS) and side effecting functions being code

Command-Query Separation and Immutable Builders

Matthew Podwysocki's Blog — Tue, 06 May 2008 21:00:37 GMT

In one of my previous posts about Command-Query Separation (CQS) and side effecting functions being code

Command-Query Separation and Immutable Builders

Matthew Podwysocki — Tue, 06 May 2008 20:58:56 GMT

In one of my previous posts about Command-Query Separation (CQS) and side effecting functions being code

re: Manage states in a multi-threaded environment without the synchronization pain

Patrick Smacchia — Tue, 06 May 2008 08:09:07 GMT

Jared,

I think there is a misunderstanding. The Debug.Assert(...) you are referencing is here to enforce the object / resource affinity and not to detect a race condition.

I agree that race conditions problems sometime don't appear in release mode and thus, contract with Debug.Assert(...) can sometime be not helpful. Also, a shared state can be sane during the execution of Debug.Assert(..) and corrupted just during the execution of the next instruction.

Reflective Perspective - Chris Alcock » The Morning Brew #87

Reflective Perspective - Chris Alcock » The Morning Brew #87 — Tue, 06 May 2008 07:23:38 GMT

Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #87

h 264 explained

h 264 explained — Tue, 06 May 2008 06:50:53 GMT

Pingback from h 264 explained

re: Manage states in a multi-threaded environment without the synchronization pain

Jared Parsons — Tue, 06 May 2008 04:12:53 GMT

Good post but one point I don't agree with.

Debug.Assert( MyHelperPlumbing.CurrentThreadIsInitialThread() );

A debug assert is great but ideally this should be a retail contract vs. a debug assert. As you pointed out debugging race conditions is a nightmare at best. This type of check can be invaluable when tracking down a race condition bug. Unfortunately there are many race conditions that just don't repro in debug code. Moving this to a retail contract will help ensure that 1) your code fails and fails fast and 2) you learn about the race condition at the earliest possible moment.

re: Manage states in a multi-threaded environment without the synchronization pain

Granville Barnett — Mon, 05 May 2008 12:38:42 GMT

Interesting.

I have always been a fan of the immutable approach despite its larger memory demand - but like you say the cost of synchronisation is steep.

Dew Drop - May 5, 2008 | Alvin Ashcraft's Morning Dew

Dew Drop - May 5, 2008 | Alvin Ashcraft's Morning Dew — Mon, 05 May 2008 12:32:44 GMT

Pingback from Dew Drop - May 5, 2008 | Alvin Ashcraft's Morning Dew

New and Notable 237

Sam Gentile — Mon, 05 May 2008 11:37:42 GMT

Identity Management/OpenID/Security/P2P/WCF Scott Hanselman has a great post on OpenId P2P and WCF: Some

Link Listing - May 4, 2008

Christopher Steen — Mon, 05 May 2008 09:31:14 GMT

ASP.NET ASP.NET "Head" Rendering Issues! [Via: jlynch ] WPF Cool WPF MulticolumnTreeview [Via: DotNet...

Link Listing - May 4, 2008

Christopher Steen — Mon, 05 May 2008 09:30:51 GMT

Link Listing - May 4, 2008

Manage states in a multi-threaded environment without the synchronization pain

Patrick Smacchia [MVP C#] — Mon, 05 May 2008 05:31:13 GMT

I see 4 common ways to deal with states in a multi-threaded environment: Immutable objects : The idea

760 com

760 com — Sat, 03 May 2008 19:38:10 GMT

Pingback from 760 com