Process thread synchronization problems

1. critical_section

 

Related Operations:

Initializecriticalsection
Entercriticalsection
Leavecriticalsection
Deletecriticalsection
Tryentercriticalsection // If the resource is occupied, false is returned instead of waiting for sleep.

Initializecriticalsectionandspincount (a, B) // B will be ignored in a single processor
Setcriticalsectionspincount (a, B )//

 

Struct rtl_critical_section
{
Prtl_critical_section_debug debuginfo;
Long lockcount;
Long recursioncount;
Handle owningthread;
Handle locksemaphore;
Ulong_ptr spincount;
};
Struct rtl_critical_section
{
Prtl_critical_section_debug debuginfo;
Long lockcount;
Long recursioncount;
Handle owningthread;
Handle locksemaphore;
Ulong_ptr spincount;
};

Debuginfo this field contains a pointer pointing to the companion structure allocated by the system. The type of this structure is
Rtl_critical_section_debug
Lockcount is the most important field in the critical section. It is initialized as a value-1. Here lockcount is 1, which means that apart from a thread, there is another thread waiting for it. It is increased by entercriticalsection and reduced by leavecriticalsection. ("When this value is equal to or greater than 0, this critical section is occupied. When it is not equal to-1, the owningthread field contains the thread ID that owns this critical section. The difference between this field and the value (recursioncount-1) indicates how many other threads are waiting to obtain the critical section.) This is the information on the Internet. I did not seem to have tested it like this, if you know the relationship between the two, leave a message.

Recursioncount this field is the number of times this thread recursively obtains the critical section. The initial value is 0. If the value is zero, the next thread that attempts to obtain the critical section will succeed.

Owningthread this field contains the thread identifier of the thread currently occupying this critical section. The thread ID is the same as the ID returned by APIs such as getcurrentthreadid. If the thread ID is 0, the critical section is in a signal state.
Locksemaphore is actually an auto-Reset event, not a signal. It is a kernel object handle used to notify the operating system that the critical section is currently idle. The operating system automatically creates a handle when a thread attempts to obtain the critical section for the first time but is blocked by another thread that already has the critical section. Deletecriticalsection should be called (it will issue a closehandle call that calls the event and release the debug structure if necessary), otherwise the resource will leak.
Spincount is only used for multi-processor systems. In a multi-processor system, if the critical section is unavailable, the call thread rotates dwspincount times before waiting for the signal related to the critical section. If the critical section becomes available during the rotation operation, the call thread avoids waiting for the operation. Rotating counting can provide better performance on a multi-processor computer because rotating in a loop is usually faster than waiting in kernel mode. The default value of this field is zero, but you can use initializecriticalsectionandspincount API to set it to a different value.