windows: Fix a race condition when removing file map handles.

We hold a lock on the handleMap while we remove an addr/handle
pair from it, but we need to also include the UnampViewOfFile in
the map. There was a window of opportunity for the OS to re-use
the addr for a new map, and if the goroutine which mapped that addr
also unmapped it before we tried to remove our handle from
handleMap, we would find that our handle was missing from handleMap.

mmap_windows.go

@@ -101,13 +101,18 @@ func unlock(addr, len uintptr) error {
 
 func unmap(addr, len uintptr) error {
 	flush(addr, len)
+	// Lock the UnmapViewOfFile along with the handleMap deletion.
+	// As soon as we unmap the view, the OS is free to give the
+	// same addr to another new map. We don't want another goroutine
+	// to insert and remove the same addr into handleMap while
+	// we're trying to remove our old addr/handle pair.
+	handleLock.Lock()
+	defer handleLock.Unlock()
 	err := syscall.UnmapViewOfFile(addr)
 	if err != nil {
 		return err
 	}
 
-	handleLock.Lock()
-	defer handleLock.Unlock()
 	handle, ok := handleMap[addr]
 	if !ok {
 		// should be impossible; we would've errored above