From http://msdn.microsoft.com/en-us/library/windows/desktop/aa366895(v=vs.85).aspx
There is no lock count for virtual pages, so multiple calls to the VirtualUnlock function are never required to unlock a region of pages.
And remembering that a page in Windows is 4kb, and that the keys we use are much much smaller, we get that if you allocate two private keys that get to be in the same memory page and then one of the two is freed, it will probably VirtualUnlock the other key. Woops.
Ouch. If this is true, it'd be safer to allocate a locked memory pool once and then distribute from that (and maybe increase the size as needed), instead of trying to lock/unlock on allocation/deallocation every time. That'd likely also improve performance.
Boost.Pool could probably help here.
/subscribe
Please don't do that (/subscribe). Only comment if you have something to add. Mind that everyone on the thread gets email when you post.
Sorry, as this is a Windows thing and I'm interested in further replies but couldn't add anything to it currently I did that. Would be nice to have an subscribe to this issue option. Won't do this again!
I'll add that this problem isn't Windows only: http://man7.org/linux/man-pages/man2/mlock.2.html
Memory locks do not stack, that is, pages which have been locked several times by calls to mlock() or mlockall() will be unlocked by a single call to munlock()