MSDN Magazine - December 2007 - (Page 25) lock! In naïvely written code, if an async exception occurs, the finally block to release the lock will not run and you may cause other threads to block indefinitely. Do not define your own locks unless you are a true expert when it comes to memory models and concurrency and you have demonstrated a need for a better lock. Beyond the obvious pitfalls like alertable waits and how to spin on hyper-threaded CPUs,your lock must also cooperate with the CLR’s escalation policy,which needs to keep track of whether each thread is holding a lock.Thread.BeginCriticalRegion and EndCriticalRegion can help the CLR identify when third-party locks are acquired and released. Hard and Soft OOM Conditions There is another mitigation technique besides AppDomain unloading for out-of-memory errors. The MemoryFailPoint class will attempt to predict whether a memory allocation will fail.You allocate a MemoryFailPoint for X megabytes of memory, where X is an upper bound on the expected additional working set for processing one request.You then process the request and call Dispose on the MemoryFailPoint. If there is not enough memory available,the constructor throws an InsufficientMemoryException, which is a different exception type used to express the concept of a soft OOM. Apps can use this to throttle their own performance based on available memory. The exception is thrown before memory is actually allocated, when no corruption has occurred yet.Thus,this implies that there is no corruption of shared state and therefore there is no need for an escalation policy to kick in. MemoryFailPoint does not reserve memory in the sense of reserving or comunless you are a true expert mitting physical pages of when it comes to memory memory,so this technique models and concurrency and is not iron-clad—you can get into races with other you have demonstrated a heap allocations in the need for a better lock. process.But this technique does maintain an internal process-wide reservation count to keep track of all threads using a MemoryFailPoint in the process.And we believe this can reduce the frequency of hard OOMs requiring invocation of the framework’s escalation policy. Code download available at msdn.microsoft.com/msdnmag/code07.aspx. Send your questions and comments to clrinout@microsoft.com. Alessandro Catorcini is a Lead Program Manager in the CLR team. In Visual Studio 2005 he was responsible for the hosting API layer and CLR integration into SQL Server 2005. Brian Grunkemeyer has been a Software Design Engineer on the .NET Framework since 1998. He has implemented a large portion of the Framework Class Libraries, as well as cross-cutting features, such as generics, managed code reliability, and versioning considerations. CLR Inside Out december2007 25 http://msdn.microsoft.com/msdnmag/code07.aspx http://www.quicklearn.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.