Minor threading update

I made some very minor updates to the threading guidelines... Please let me know if there are questions or comments.

 

 

Do not lock on any public types or other instances you do not control.  Notice the common construct:
lock (this)
violates this guideline if this is publicly accessible.

Do be aware that lock() is not cheap

Perhaps your caller should do the locking?
Granularity trade-off – concurrency vs. cost
Consider Interlocked.Exchange, R.W.Lock

Do use the ThreadPool for best performance

Do strive to not create architectures that expose threading issues to the user For example, ASP.NET has great scaling, but users never deal with threading

 

Published 12 November 03 05:12 by BradA

Comments

# Anonymous said on November 12, 2003 7:09 PM:
Hmm, why exactly is lock(this) bad? It seems to me that depends on the desired semantics. It is certainly the obvious way to expose your lock object so your caller can participate as well.
# Roy Osherove said on November 12, 2003 7:35 PM:
Where are all those guidelines located? Can they be downloaded somewhere?
# Junfeng said on November 13, 2003 12:15 AM:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp Brad's blog is incremental update of the guideline in the link.
# Brad Abrams said on November 13, 2003 2:42 AM:
on why lock(this) is bad... i just had the same debate today with the ASP.NET dev lead.... This guideline is intended to reduce deadlocks caused by your component and client code locking on the same syncblock... if the client code can't see your types, they can't lock on them. they can still deadlock on their own types, but then it is all their problem... the fix is easy.. public class A { … lock(this) { … } … } to this: public class A { private Object thisLock = new Object(); … lock(thisLock) { … } … }
# Marius said on November 13, 2003 3:53 AM:
I have a question related to the ThreadPool. Why can't we change the thread priority of a thread pool ? and another one....WHY we can't set the REAL_TIME priority of a thread from managed code ? I mean...come on...what is the reason for this ?
# Brad Abrams said on November 14, 2003 8:09 PM:
He Marius, I got this feedback from the team on your question: we have only one thread pool in the whole process and don't want to allow an option to set the priority since you might be setting it for other people who are using the thread pool in the same process as well (which might result in unexpected behavior).
# Marco Russo said on November 18, 2003 4:55 AM:
Brad, when you suggest to use ThreadPool for better performance, remember to warn against CAS behaviour different than async calls (that maintain CAS context of callers).
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