Linked by Thom Holwerda on Sun 2nd Dec 2007 22:41 UTC, submitted by Amit Bahree
Thread beginning with comment 288075
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Another framework. Great
by jayson.knight on Mon 3rd Dec 2007 13:14
in reply to "RE: Another framework. Great"
RE[2]: Another framework. Great
by Vanders on Mon 3rd Dec 2007 19:16
in reply to "RE: Another framework. Great"
For non-functional languages, locks are an (if not THE) imperative part of multi-threaded application design, unless you want race conditions and deadlocks all over your application.
Not if you're using message passing. I'm not going to claim that locks are not required at all, but good design and message passing can help eliminate them.
RE[3]: Another framework. Great
by jayson.knight on Mon 3rd Dec 2007 19:34
in reply to "RE[2]: Another framework. Great"





Member since:
2005-07-06
"The .NET framework is on version 3.5, while the CLR is still stuck on 2.0."
The CLR version is the same as the .Net version: http://msdn2.microsoft.com/en-us/library/ms230176(VS.90).aspx This is because .Net is the umbrella term for CLR + BCL + CLI (actually, the CLR is MS's implementation of the CLI). Regardless, we are now on v3.5 of the CLR.
"-Do not use locks."
For non-functional languages, locks are an (if not THE) imperative part of multi-threaded application design, unless you want race conditions and deadlocks all over your application.
I'd also love to know what these performance problems are that you speak of. It has been shown on numerous occasions that a properly designed .Net app has performance approaching that of unmanaged code.
Edited 2007-12-03 13:13