Analysis on constructing ASP. NET thread security set

Most ASP. NET thread-safe sets have some fundamental defects: although each operation is thread-safe, multiple operations cannot be used together. This means that some basic execution sequence, such as checking the number of elements in the stack before the top element pops up, may pose a potential risk. Although some APIs have tried to bind some operations such as. NET 4's Coordination Data Structures, they often introduce ugly methods such as TryDequeue ).

Collections in. NET 1 try another way, they expose a SyncRoot attribute, rather than locking it internally. Although SyncRoot is still the default mechanism for synchronizing objects,. NET 2 has abandoned the SyncRoot/Wrapper design mode.

How can we create an available combined API? Jared Parson believes that the set should not be exposed directly to ASP. NET thread-safe API, all methods should belong to a temporary object, and this object is created only when you lock the set. This temporary object is the "key" of the set. Only the holder of the key can obtain the set content.

The following example shows the thread security queue of Jared Parsons:

 
 

  
  
static void Example1(ThreadSafeQueue queue) {    
  
  
  using (var locked = queue.Lock()) {       
  
  
   if (locked.Count > 0) {         
  
  
     var first = locked.Dequeue();       
  
  
    }    
  
  
  }  
  
  
} 
 
 

Objects named locked are not ASP. NET thread-safe, but developers can perform operations correctly only in the using code block. After following this simple rule, all the code in the development block is thread-safe. Jared explains:

Like most ASP. NET thread security designs, these codes are still misused:

1. Use ILockedQueue after it is destroyed. This approach should be disabled. The user's existing knowledge is generally enough to avoid this problem. In addition, some static check tools, such as FxCop, recognize this practice as an error. We can also use a more rigorous approach to prevent such situations: Add a disposed flag and check each method.

2. If you retain a value such as Count when crossing multiple Lock statements, you may make incorrect judgments and assumptions about the condition of the set.

3. If the user does not properly destroy ILockedQueue, the object will be permanently locked. Fortunately, for objects that implement IDisposable, FxCop also recognizes this practice as an error-although this is not a 10 thousand-point secure mechanism.

4. You cannot determine whether the user will hold the ILockedQueue object for a long time. Although IDisposable generally contains the meaning of "short-term", it cannot be perfectly guaranteed.

5. ILockedQueue is NOT thread-safe. Although the user generally does not give the IDisposable object to multiple threads for use, this is also a situation that must be taken into account.

This article describes how to build an ASP. NET thread security set and hopes to help you.

1. Introduction to ASP. NET cache and Its Application
2. Analysis and Practice of ASP. NET Cache
3. Analysis of ASP. NET database cache
4. Custom Control DateTimePicker of ASP. NET source code
5. Analysis of ASP. NET File Download Functions