MSDN Magazine - December 2007 - (Page 20) Keeping a lock count on each thread informs our escalation policy whether a thread may potentially be editing shared state. Each AppDomain gets its own copy of static variables. While threads can cross AppDomain boundaries, it is (almost) impossible to initiate communication across an AppDomain boundary without using .NET remoting or a similar technique.AppDomains give you a relatively firm boundary to contain code. If an asynchronous exception occurs on a thread, you must decide how much corruption might be present and how to be resilient to that specific level of corruption. expose them to other threads, only those temporary objects can be corrupted. But if a thread is writing to shared state, that shared resource may be corrupted,and other threads may potentially encounter this corrupted state.You must not let that happen. In this case, you abort all the other threads in the AppDomain and then unload the AppDomain. In this way, an asynchronous exception escalates to an AppDomain,causing it to unload and ensuring that any potentially corrupted state is thrown away.Given a transacted store like a database,thisAppDomain recycling provides resiliency to corruption of local and shared state. State Corruption Detecting Shared State Figuring out whether a thread is modifying shared state is not the easiest problem.It’s not obvious in most code whether the value of a local variable on the stack was initialized locally,whether it was passed in as a parameter to the method, or whether it simply refers to an object that is stored in a static variable (or is reachable from a static variable). A subtle demand about modifying shared state comes from the concurrency space: whenever you edit a static variable, your code almost inevitably holds a lock. So keeping a lock count on each thread informs our escalation policy as to whether a thread may potentially be editing shared state. It’s true that locks are often taken while reading from shared state and no state corruption occurs while reading from shared state (assuming there is no lazy There are three buckets that state corruption may fall into. The first is local state, which includes local variables and heap objects that are only used by a particular thread. The second is shared state, which includes anything shared across threads within the AppDomain, such as objects stored in static variables. Caches often fall into this category.The third is process-wide,machine-wide, and cross-machine shared state—files, sockets, shared memory, and distributed lock managers fall into this camp. The amount of state that can be corrupted by an async exception is the maximum amount of state a thread is currently modifying. If a thread allocates a few temporary objects and doesn’t Read, create and edit PDF! with PDFKit.NET 2.0 20 msdnmagazine CLR Inside Out http://PDFKit.NET http://www.tallcomponents.com http://www.tallcomponents.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.