How to determine whether the code is in a critical section

Have such a problem

A reader asked: When an exception occurs, if you don't know whether to clean up the critical area object, what is the appropriate exception handling method?

The reader’s question is this:
"I am using SEH. In the code, I use __try/__except blocks to protect the code that enters and exits the critical section. When an exception occurs, I don’t know if I’m still critical. The zone has already come out. Even if I use __try/__finally this way, it has not solved my
problem."

Answer to the question: You can know whether you own the critical section object, because once you enter, it means you have acquired the critical section object.

Method 1: Judge by instruction pointer

"If the code executes here, it means I must be in the critical section."

 

Please note that the above method can also work normally for nested calls to EnterCriticalSection.
If you get the critical section again, you must remember to include the call in its own try/finally structure.

Method 2: Judge by stack variables

"I remember if I have entered the critical zone"

 

The above method can also be applied to nested calls to EnterCriticalSection. Just remember that every time you get a critical section object, you must add 1 to cEntered.

Method 3: Tracking through objects

Encapsulate CRITICAL_SECTION into an object.
This method is most suitable for the situation of the reader above.

 

Please note that the above code does not apply to nested critical sections. If you try to get the critical section object twice, the exception handler will only exit the critical section once.

Please also note that we consider the critical section to be unacquired in the initial state and add assertions. If it happens to have obtained the critical section, our cleanup code will try to exit the critical section, but it does not actually enter. (Imagine if there is an exception in the first "...".)

Method 4: Judging by smart objects

By encapsulating the CRITICAL_SECTION object into a smart object.
You can add the following method to the above code: DWORD Depth() {return Owned()? M_dwDepth: 0;}

code show as below:

 

Cleaning up when an exception occurs in a critical section will lead to such a question: How do I know that the cleaning operation is safe?
You use the critical section to indicate that you want to use a data structure exclusively, but if an exception is found when obtaining the critical section, the state of the data structure is unstable. If simply exiting the critical section will cause the data structure to enter an inconsistent state, it will lead to a difficult to diagnose question: Why is my reference count not synchronized?
I will have more about exceptions later.

At last

Raymond Chen's "The Old New Thing" is one of my favorite blogs. It contains a lot of little knowledge about Windows, which is really helpful for the majority of Windows platform developers.
This article is from: "How do I determine whether I own a critical section if I am not supposed to look at internal fields?"

Guess you like

Origin blog.csdn.net/mmxida/article/details/108411221