Amazon.com Widgets

A couple of great CLR concurrency papers

I just ran across these and thought they are worth sharing:

 

http://research.microsoft.com/~birrell/papers/ThreadsCSharp.pdf

http://msdn.microsoft.com/msdnmag/issues/05/08/Concurrency/default.aspx

 

Enjoy!

Published 07 August 05 08:43 by BradA
Filed under:

Comments

# Joku said on August 8, 2005 2:10 PM:
Quote from the first link:

"When you are programming with threads, you usually drive slow devices through synchronous library calls that suspend the calling thread until the device action compltes, but allow other threads in your program to continue. You will find no need to use older schemes for asynchronous operation (such as i/o completion routines)."

Wha ha? I always thought using the Begin... End... asynchronous methods to take advantage of IO completion ports in network programming on .NET was the preferred method when scalability/performance was necessary. This quote seems to suggest that it is "older scheme". What should I make of this, write my future programs using other than Begin... End... when using socket and stream classes?
# Judah said on August 8, 2005 10:16 PM:
I predict that multithreading will remain an inexact and difficult science until we get language abstractions and compilers that force developers to write safe multi-threaded applications.

Even as a .NET 'veteran', I still find it difficult -- extremely difficult! -- to write good, mulithreaded code that has zero problems with it.
# Joku said on August 9, 2005 3:00 AM:
This is a nice article about sockets in .NET:

http://msdn.microsoft.com/msdnmag/issues/05/08/HighPerformanceSockets/default.aspx

The conclusion seems to be that you pick either more performance or better scalability. I guess you can get both but that probably comes at the cost of going lower level and subtle problems that come with more complexity.

Well choice is good :-)
# Peter Ritchie said on August 9, 2005 1:57 PM:
Birrell seems to use the "lock" statement exclusively and does not offer a correct way to obtain mutual exclusion without deadlock avoidance. The "lock" statement has no timeout options. The best practice seems to be to use Monitor.TryEnter() instead:
if (Monitor.TryEnter(this, 300))
{
try
{
// Place code protected by the Monitor here.
}
finally
{
Monitor.Exit(this);
}
}
else
{
// Code to execute if the attempt times out.
}
# Jason Haley said on August 9, 2005 8:12 PM:
# Boxing » Blog Archive » Betsy Aoki’s WebLog : Just a bit of useless timewasting said on January 5, 2008 1:32 AM:

PingBack from http://boxing.247blogging.info/?p=474

New Comments to this post are disabled

Search

Go

This Blog

本博客中文版 (View in Chinese)



These postings are provided "AS IS" with no warranties, and confer no rights.

Syndication

Page view tracker