title: Question about memory page protection
body: <p>Here's another question I met when reading &lt; Windows via C/C++ 5th Edition >. First, let's see some quotation.</p>
  
  <pre><code>LPVOID WINAPI VirtualAlloc(
    __in_opt  LPVOID lpAddress,
    __in      SIZE_T dwSize,
    __in      DWORD fdwAllocationType,
    __in      DWORD fdwProtect
  );
  </code></pre>
  
  <blockquote>
    <p>The last parameter, fdwProtect,
    indicates the protection attribute
    that should be assigned to the region.
    <strong>The protection attribute associated with the region has no effect on the
    committed storage mapped to the
    region.</strong></p>
    
    <p><strong>When reserving a region, assign the protection attribute that will be used
    most often with the storage committed
    to the region.</strong> For example, if you
    intend to commit physical storage with
    a protection attribute of
    PAGE_READWRITE, you should reserve the
    region with PAGE_READWRITE. <strong>The
    system's internal record keeping
    behaves more efficiently when the
    region's protection attribute matches
    the committed storage's protection
    attribute.</strong></p>
    
    <p>(When commiting storage)...you usually
    pass the same page protection
    attribute that was used when
    VirtualAlloc was called to reserve the
    region, <strong>although you can specify a
    different protection attribute.</strong></p>
  </blockquote>
  
  <p>The above quotation totally puzzled me.</p>
  
  <ul>
  <li><p>If the protection attribute associated with the region has no effect on the committed storage, why do we need it?</p></li>
  <li><p>Since it is recommended to use the same protection attribute for both reserving and committing, why does Windows still offer us the option to use different attribute? Isn't it mis-leading and kind of a paradox?</p></li>
  <li><p>Where exactly is the protection attribute stored for <strong>reserved region</strong> and <strong>committed storage</strong>, repectively?</p></li>
  </ul>
  
  <p>Many thanks for your insights.</p>