The old new thing-read windows programming revelation

By Fei Tian

I recently read Raymond Chen'sThe old new thingChen is a Senior Software Engineer in Microsoft Windows. In general, this is a very valuable book. Its value is embodied in the detailed analysis of the Windows system-about windows, I think a book highly praised by many windows developers is "Windows core programming". The book "core programming" can be regarded as a revision of the operating system textbook to some extent, the process, thread, synchronization, memory, and I/O chapter is indeed a good reference tool for win programming. But the book revelation is another style. The author cares about some interesting details of the win system, such as Win window management and its internal mechanism, VC ++ compiler, backward compatibility, international programming, win security mechanism, etc. It is written into a chapter in funny languages, another kind of reference is provided: "It turns out that there is a reason for the design like windows! "So for win developers who have taken care of classic textbooks, reading this book should be very rewarding in terms of details.

As you may know, this book can be divided into two parts: Windows design and Windows development. The first part is relatively simple and attractive, starting from Win95, the author explains many reasons for the design of the win UI, such as why there is a start button and why the Shutdown option should be placed in the Start medium. The latter part is difficult to understand and is also suitable for developers to read well. It involves many implementation details of the win system. Among them, I would like to see Chapter 1 General Software Issues, as mentioned by the author: although these topics may take windows as their starting point, they are nonetheless applicable to software development in general. I would like to share some experiences with you.

ManyProgramWhen a programmer writes a program, he will think of Optimization-time and space. But do you have the feeling that the optimization strategy you have racked your brains to come up, in the end, it took more time and cost? Chen gave us a very simple example-imagine a simple small program to get the return address of the current function. Such a program can be easily implemented through the compiler's inline function _ returnaddress:

LeftCodeIt is a C ++ program, and the corresponding assembly code is on the right. At this time, intelligent people may think: Why is it so troublesome? A pop Command won't work out:

In the above program, the pop command directly sends ESP to currentinstruction, and the two commands v. S. Four. Obviously, the two commands won! However, the opposite is true.

In fact, the x86 processor hides a lot of things we may not be able to see in the processor manual-for example, in addition to the familiar program call stack, for optimization, the processor also customizes a "Return prediction" stack for the call/RET command: when a call command is executed, the processor will return the address (ESP) press into the "back to prediction" stack (of course, it will also press into the normal call stack), when the RET command is encountered, the corresponding pop operation, and the processor will do speculation: it considers that the stack top of the "back to prediction" Stack is the address that should be returned. Therefore, first move the return address to the stack top address of the returned prediction stack. If there is any problem, perform related Error Correction operations. In this way, the disadvantages of the second method come out: it adds an additional call command without the corresponding RET command. Of course, the correctness is certainly correct, but the consequence is that the top stack of the prediction stack is -- L1! The pop command does not work on the returned prediction stack, so that when the current program returns, the processor will simply set the return address to L1 -- followed by the error code of continuously processing the page fault pressure stack. page fault: Error Code of processing the pressure stack... It will naturally take a longer time!

Return address Predictor Stack:		L1	->	Caller1	->	Caller2	->	Caller3	->	...
Actual Stack:		Caller1	->	Caller2	->	Caller3	->	Caller4	->	...

Another "sensitive issue" mentioned by the author is memory leakage-malloc \ calloc \ relloc \ free \ Delete... As mentioned by the author, the common cause of a low server performance or even a crash is paging. Why is it? Why is the memory insufficient? Memory leakage!

Here, we often have a way of thinking when managing memory: when allocating memory, we allocate the largest memory. When recycling the memory, we recycle the largest memory (if it is larger than the memory area currently in custody ), this two-pronged approach ensures that there is an effective memory for me to use. What about this performance? Think about the best fit allocation and worst fit allocation mentioned in the OS class? The author provides a simple implementation of this idea:

The left side can be considered as a simple heap manager, while the right side is the code for the manager to allocate and recycle memory. getbuffer is used to request memory from the manager, and returnbuffer is used to return memory (I .e. recycle) to the manager ), by referring to an error in the original book: The second line of code of getbuffer localsize (m_pcache)> = CB, the original book became <= CBJ

This simple and secure idea proves that a large amount of memory is wasted, because the actual memory requests are mostly small-sized requests and the heap manager recycles mostly small-sized memory. For small memory requests, if the maximum available memory block is allocated to it, it will cause a lot of waste. But when an occasional large memory request arrives, it is very likely that there is no new memory available for use-the original large block memory is allocated with a small block request meeting the higher probability, so we need to re-open a new large block of memory! Even if a large block has been returned at a certain time, the memory requests may be small blocks. This large memory area is wasted, so it can be repeated, it will certainly cause a large amount of memory leakage (as a matter of fact, we cannot strictly calculate the leakage. After all, the memory is managed securely, however, all these occur during the execution of the malloc calloc free functions)

What is the solution? It is very easy. Only small memory blocks can be recycled when memory is recycled. A simple modification:

Note the red part: we only need to recycle a relatively small amount of memory, and we do not reserve a large amount of memory, but we just need to simply free it. What are the benefits of doing so? We don't need a lot of memory. In this way, we only ensure that the idle memory blocks currently owned by the manager are not that large, this ensures that most small memory requests can be met without memory waste. Only large memory requests need to be re-allocated, however, when a large part of memory is used up and collected, it is easy to free up as per the current method. This is a "right remedy" method? For most small block memory requests, why do we have to allocate the maximum block memory? Just a small part.J

In short, there are countless examples like this in Windows programming book, this book does provide us with a lot of new perspectives, so that we can better understand some details of the Windows system. Unfortunately, I have not finished reading it yet. I only want to read it carefully when I have a lot of free time. I also hope that friends who are interested in time can read it well, I believe this will inspire you a lot ~