title: Can address space be recycled for multiple calls to MapViewOfFileEx without chance of failure?
body: <p>Consider a complex, memory hungry, multi threaded application running within a 32bit address space on windows XP.</p>
  
  <p>Certain operations require n large buffers of fixed size, where only one buffer needs to be accessed at a time.</p>
  
  <p>The application uses a pattern where some address space the size of one buffer is reserved early and is used to contain the currently needed buffer.</p>
  
  <p>This follows the sequence:
  (initial run) VirtualAlloc -> VirtualFree -> MapViewOfFileEx 
  (buffer changes) UnMapViewOfFile -> MapViewOfFileEx</p>
  
  <p>Here the pointer to the buffer location is provided by the call to VirtualAlloc and then that same location is used on each call to MapViewOfFileEx.</p>
  
  <p>The problem is that windows does not (as far as I know) provide any handshake type operation for passing the memory space between the different users.</p>
  
  <p>Therefore there is a small opportunity (at each -> in my above sequence) where the memory is not locked and another thread can jump in and perform an allocation within the buffer.</p>
  
  <p>The next call to MapViewOfFileEx is broken and the system can no longer guarantee that there will be a big enough space in the address space for a buffer.</p>
  
  <p>Obviously refactoring to use smaller buffers reduces the rate of failures to reallocate space.</p>
  
  <p>Some use of HeapLock has had some success but this still has issues - something still manages to steal some memory from within the address space.
  (We tried Calling GetProcessHeaps then using HeapLock to lock all of the heaps)</p>
  
  <p>What I'd like to know is there anyway to lock a specific block of address space that is compatible with MapViewOfFileEx?</p>
  
  <p>Edit: I should add that ultimately this code lives in a library that gets called by an application outside of my control</p>