Why use Lock (classname) or synclock gettype (classname) is an error, the performance designer and senior Microsoft Developer's performance designer and senior Microsoft Developer's performance designer and senior Microsoft developer communicate with Dr. Gui in an email. A quite common approach (unfortunately, this practice has also mentioned in some of our documents, although we will make a revision) actually there is a big problem. He asked for Dr. Gui to help publish your news and told the programmaker to use this approach. Ph.D. is of course very happy to help. What is this very common approach? In fact, it is to lock the type object. In C #, the locking method is Lock (classname), where className is a name of a class; in Microsoft Visual Basic .NET, the locking practice is SyncLock gettype (classname). Background Knowledge: In multi-threaded programming, the Lock / SyncLock statement is used to create a critical portion or a brief part of only one thread in the code. (If you need to update multiple fields in the object, you may need this statement - you want to make sure that other threads do not attempt to update this object at the same time!) This statement will lock the only monitoring object associated with the object you specify, if Other threads have locked the monitoring object, wait. Once it lockeds the monitoring object, any other thread cannot lock the monitoring object unless your thread is locked, the unlocking will occur automatically at the end of the closed block. One common usage is to lock this / me quote, so that only your thread can modify the object you are using - however, a better way is to lock the specific object you are about to modify. The advantage of locking as small as possible is to avoid unnecessary waiting. GetType and TypeOF returns a reference to the type object of this type. The type object of the System.Type type contains methods that enable you to reflect the type, which means you can find its fields and methods, and even access fields and call methods. Once you have a reference to the type object, you can create an instance of the object (and if you use the Type.GetType Shared / Static method, you can get a reference to the type object by name). Therefore, the type object is very convenient. However, some programmers like "abuse" in this way, thereby replacing STATIC / Shared objects that can be locked. (Unfortunately, we mentioned this method in C # documents and Visual Basic .NET documents, this is a proposed approach.) In this case, the suggestions in these documents are wrong (we Correct). This approach is unacceptable, not to mention it. The reason is this: Since all instances of a class have only one type object, the lock type object is equivalent to the static object contained in the lock class from the surface. As long as you lock all instances of the class, wait until you have any part of any of the other threads, then lock access, so you can securely access static members without being interfered with other threads. This approach is indeed, at least in most cases.
But it also has some questions: First, get the type object is actually a very slow process (although most programmers think this process is very fast); secondly, other threads in any class, even in the same application domain Other programs running can access this type of objects, so they may be able to lock the type object instead of you, fully block your execution, causing you to hang. The basic problem here is that you do not have this type of object, and you don't know who can access it. In general, relying on lock is not created by you, and you don't know who can access the object is a very bad practice. This is easy to cause a deadlock. The safest way is to lock only private objects. But in addition, there is a more serious problem. Since the type object is sometimes shared between the application domain (but not between the processes) because of the current version of the .NET runtime. (Usually there is no problem because they are constant.) This means that another application running in other application domains (but in the same process) is possible to lock the type object you want to lock, and Never release this type of object to make your application deadlock. And, this can easily obtain access rights of type objects because the object has a name - the fully qualified name of this type! Keep in mind that Lock / Synclock will have been blocking (this is a hang-in-provision) until it can be locked. Obviously, the object that relies on locking other programs or components that can be locked is not a good practice, and will cause a deadlock. This is still a bad approach even if this type of object is in your application domain, because any code can access public type type objects, resulting in deadlocks. If your components you are using in your app are not your written, this approach is particularly problematic. (Even if the Lock (this) / Synclock Me may have this problem, others may lock you. Even if this happens, the root of the problem may be more likely to find the deadlock caused by the lock type object, Because your object is not a global availability of the cross-care program domain.) So what should I use? Very simple: as long as you declare and create an object as a lock, then use it instead of the type object to lock. Typically, in order to copy the semantics of the problem code, you will want this object to be static / shared - of course, it should be private! In short, you can change the following problem code: Lock (TypeOf (foo)) {// bad code! ?? // statements;} to the following correct code: lock (someprivateStaticObject) {// good code!?? // statements;} Of course, you must already have a private static object to be locked (if you use the lock to modify the static object, you may already have one!) or you must create one. (Make it a private object to avoid other classes to lock your object.) Do not try to lock the fields that are not reference (object) types, such as int / integer. The compiler error will occur. If you do not have a private static object to be locked, you may need to create a dumb object: class myclass {?? private static object {?? private static object = new object (); ?? // methods of class Go Here - can lock someprivateestaticObject}
