Errors Caused by using Windows kernel objects (VC ++ 6.0)

Related Knowledge:

1. Kernel objects mainly include:
Access symbol object, event object, file object, file ing object, I/O completed port object, job object, mailbox object, mutex object, pipeline object, process object, Beacon object, thread object

2. The data structure of the kernel object can only be accessed by the kernel. Therefore, applications cannot access the data structure in the memory and directly change their content. Therefore, they must call the Windows interface to operate the kernel object.

3. Using Kernel Object naming allows processes to access across process boundaries. Microsoft does not provide guidelines for naming kernel objects. All these objects share a single namespace.

Real instance:

Using mfc6.0

In a C ++ network programming, I customized an exsocket class that inherits the casyncsocket class. Because the amount of data sent and received is large, I used data buffering, one thread is responsible for receiving and storing data in the buffer. The other thread is responsible for extracting and processing data from the buffer. In the access buffer, cmutex is used for mutex access. Typical relationships between producers and consumers:

File exsocket. h:

Class exsoket: Public casyncsocket
{
PRIVATE:
Cmutex * pmutex; // mutex for critical section
Messagenode * pmessagehead; // head of data list
Messagenode * pmessagetail; // tail of data list
// Other variables

Public:
Exsocket (); // The Constructor
// Other functions
}

File exsocket. cpp:

Exsocket: exsocket ()
{
// Initialization of the class
Pmutex = new cmutex (false, "exsocketmutex ");
}
// Other definition of the functions

After I wrote this class, I established a connection on different machines to test the function. Everything was normal and I thought it was safe. Who knows that there was an error when I actually called it for others, at that time, I had to debug and trace the problem. I found that the error occurred when I executed csinglelock lock (pmutex). The reason was that the pmutex pointer was empty, clearly allocated in the constructor, why does it become a null pointer? Check the program is released without any other errors (this pointer is released in the destructor ).
At the end, it is also found that the first time this class is used, there will be no error, as long as the class object after the first use is not released, the second use will be wrong, check whether the original code error occurs when pmutex = new cmutex (false, "exsocketmutex ");
This statement is roughly as follows: no error is returned, and msdn does not indicate anything that can cause it to be wrong. However, when it is executed for the second time, the value returned by new is null, even if it is used in another process for the first time! That is, the use of the first process actually affects the second process!
In this case, it can only be new cmutex (false, "exsocketmutex"). This statement involves the Windows Kernel, because the kernel object can be accessed across boundaries, this mutex is implemented by naming "exsocketmutex", that is, after the first process creates an "exsocketmutex, the second process can access it through the "exsocketmutex" name, but it will fail if you continue to create this mutex object! (See Chapter 3 of Windows core programming)
Therefore, operations on kernel objects cannot be performed using conventional programming methods.
What should we do if this is mutually exclusive? Do not remove mutex. You can use the following methods to solve the problem:
File exsocket. cpp:

Exsocket: exsocket ()
{
// Initialization of the class
Cstring S;
S. Format (_ T ("exsocketmutex % d"), this); // also using sprintf (STR, "exsocketmutex % d", this); for char array Str

Pmutex = new cmutex (false, (lpcstr) S );
}
// Other definition of the functions

Since it is impossible for each class object to use the same address space, the names of all mutex objects will not be repeated, so that conflicts will not occur because multiple class objects are created. However, the same name must be used for mutual exclusion between processes.