previousupnext

1.2.3 Programming Constraints

Typical Windows NT applications employ multiple heaps. The feature of the Microsoft Visual C++ compiler that engenders this was noted in section 1.2.1 Private Heaps and Contention. Other development tools are fond of heaps too; a trivial Visual Basic program sets up half a dozen. A multiple-heap process has a memory organisation like this:


Heaps implicitly created for the C run-time library do not increase the complexity of application code, whereas private heaps created by the programmer do.

Conversely, the programmer is unlikely to free a memory block allocated from one explicitly-created heap to a different heap, but may unwittingly make this mistake with implicitly-created heaps. If memory allocated from one NT heap is freed to another, that allocation is not effectively freed, causing a memory leak. More importantly, the second heap is corrupted and the process likely to crash soon after.

The ubiquitous run-time library functions malloc and free access the private heap of the DLL from which they are called. It follows that the free of a memory block must be performed by the same DLL as the corresponding malloc. In many software designs this symmetry is neat and natural; for producer-consumer or message-passing designs it is not, allocations are freed by a different DLL and often by a different thread.

This particular feature of implicit heaps may be worked around by linking with a DLL version of the run-time library (which can bring problems of its own), but the general disadvantage remains. Multiple heaps increase the complexity of design and impose programming constraints.