关于programming的一些学习笔记

I have already outlined several reasons why executing a method asynchronously on a new Thread object is more difficult and not as efficient as using an asynchronous delegate. Because asynchronous delegates are easier to use and they provide the efficiency of using the built-in thread pool, I recommend you use them when you have to make asynchronous method calls.

There are, however, a few design situations in which delegates should not be used. The following is a list of circumstances in which you should most likely use secondary threads rather than delegates for asynchronous execution.

• You need to execute a long-running task
• You need to adjust a thread's priority
• You need a foreground thread that will keep a managed desktop application alive
• You need a single-threaded apartment (STA) thread to work with apartment-threaded COM objects

When you need to dedicate a thread to a task that's going to take a long time, you should create a new thread. For example, imagine you need to dedicate a secondary thread to watch for updates to a file or to listen for incoming data on a network socket, and you need it for the lifetime of the application. It would be considered bad style to use delegates because you would effectively be taking a thread out of the CLR thread pool and never returning it. Asynchronous method execution using delegates should only be used for relatively short-running tasks.

When you need to change a thread's priority, you should create a new thread. The Thread class exposes a public Priority property that allows you to increase or decrease the priority of a thread. However, you should not change the priority of threads from the CLR thread pool. You should only adjust the priority of the threads you have created by calling New on the Thread class.

The settings for a thread's priority level are Highest, AboveNormal, Normal, BelowNormal, and Lowest. You should generally only lower thread priorities and try to refrain from raising them. Be careful of choosing the Highest and AboveNormal settings because they can have unpredictable effects on the application and the system as a whole.

Creating a new thread is also a good idea when you want to keep a managed desktop application alive while a secondary thread is running. Imagine a scenario in a Windows Forms application where the user closes the main form while a secondary thread is performing a task in the background. Is the fact that this secondary thread is still running important enough to keep the application alive? If the secondary thread is a background thread, the answer is no. The application will shut down right away. However, if the secondary thread is a not a background thread, the app will keep running.

Each Thread object has an IsBackground property that indicates whether it is a background thread. All the threads in the CLR thread pool are background threads and should not be modified in this respect. That means a task executing asynchronously as a result of a call to BeginInvoke on a delegate is never important enough by itself to keep an application alive.

When you create a new Thread object, it is by default a foreground thread because its IsBackground property is set to false. That means your application will continue to run while a secondary thread is executing. If you would like to create a new thread and make it a background thread, you assign a value of True to its IsBackground property before you call the Start method, like so:

Dim ThreadA As Thread
ThreadA = New Thread(AddressOf TedsCode.MyAsyncTask)
ThreadA.IsBackground = True
ThreadA.Start()

Remember that whether a Thread object is a foreground or background thread is really only important when writing managed EXE-based applications such as a console application or a Windows Forms application. The IsBackground property of a Thread object has no effect on applications that have been started using a non-managed EXE such as the ASP.NET worker process.

通常，应避免锁定 public 类型，否则实例将超出代码的控制范围。常见的结构 lock (this)、lock (typeof (MyType)) 和 lock ("myLock") 违反此准则：如果实例可以被公共访问，将出现C# lock this问题。如果 MyType 可以被公共访问，将出现 lock (typeof (MyType)) 问题。由于进程中使用同一字符串的任何其他代码将共享同一个锁，所以出现 lock(“myLock”) 问题。来看看C# lock this问题:如果有一个类Class1，该类有一个方法用lock(this)来实现互斥：

publicvoidMethod2()
{
lock(this)
{
System.Windows.Forms.MessageBox.Show("Method2End");
}
}

如果在同一个Class1的实例中,该Method2能够互斥的执行。但是如果是2个Class1的实例分别来执行Method2,是没有互斥效果的。因为这里的lock,只是对当前的实例对象进行了加锁。

Lock(typeof(MyType))锁定住的对象范围更为广泛，由于一个类的所有实例都只有一个类型对象（该对象是typeof的返回结果），锁定它，就锁定了该对象的所有实例，微软现在建议，不要使用lock(typeof(MyType)),因为锁定类型对象是个很缓慢的过程，并且类中的其他线程、甚至在同一个应用程序域中运行的其他程序都可以访问该类型对象，因此，它们就有可能代替您锁定类型对象，完全阻止您的执行，从而导致你自己的代码的挂起。

锁住一个字符串更为神奇，只要字符串内容相同，就能引起程序挂起。原因是在.NET中，字符串会被暂时存放，如果两个变量的字符串内容相同的话，.NET会把暂存的字符串对象分配给该变量。所以如果有两个地方都在使用lock(“my lock”)的话，它们实际锁住的是同一个对象。到此，微软给出了个lock的建议用法：锁定一个私有的static 成员变量。