Are these actually three different concepts or am I getting jumbled? (I've been reading articles about threading and garbage collection together and have confused myself.)
"Critical section" - I think this may just be the term for sections of code that you don't want multiple threads accessing at the same time i.e. inside lock and Monitor.Enter/Exit statements?
"Critical region" - No real clue here - MSDN says something along the lines of "This tells a host that exceptions thrown within the section might have wider effect". And that "hosts of the CLR e.g. Sql Server" may choose to handle exceptions thrown within critical regions "differently". Differently how? And why? And, most importantly, in what real world scenarios might I need to mark code as a critical region?
"Constrained Execution Region" - I came across this when reading about the CriticalFinalizerObject in a garbage collection article.
All I can understand from MSDN on this one is that code within one of these regions is somehow guaranteed to run (but how?) and must therefore not throw "out-of-band" exceptions.
What is an out-of-band exception? (I did google this but it just asked me if I meant "out of bounds exception").
Is it any unhandled exception? Or only certain types of exception? And again, most importantly, in what real world scenarios might I need a "constrained execution region"?
As I don't understand the concepts at all well, I'm not sure what tags this question needs other than ".NET".
Just my understanding of these concepts:
Critical section - as you said.
Critical region - This seems the big-picture version of "don't let exceptions escape from a thread".
Constrained Execution Region - This is a way to make a piece of code more or less atomic by guarding against interruption by exceptions. The example on this page uses it to make sure that the allocation and storing of a handle are both executed. Note that there is no roll-back, it's more of a preventive system.
There are guidelines for "normal programming" that look a little like this, ie when overriding Equals or an implicit operator you should not throw (anything).