Release v0.6

Release vm-memory v0.6, with latest dirty track bitmap implementation.

Signed-off-by: Liu Jiang <gerry@linux.alibaba.com>

Author: jiangliu

CHANGELOG.md

@@ -1,6 +1,8 @@
 # Changelog
 ## [Unreleased]
 
+## [v0.6.0]
+
 ### Added
 
   - [[#160]](https://github.com/rust-vmm/vm-memory/pull/160): Add `ArcRef` and `AtomicBitmapArc` bitmap

Cargo.toml

@@ -1,8 +1,9 @@
 [package]
 name = "vm-memory"
-version = "0.5.0"
+version = "0.6.0"
 description = "Safe abstractions for accessing the VM physical memory"
 keywords = ["memory"]
+categories = ["memory-management"]
 authors = ["Liu Jiang <gerry@linux.alibaba.com>"]
 repository = "https://github.com/rust-vmm/vm-memory"
 readme = "README.md"

src/volatile_memory.rs

@@ -1563,9 +1563,12 @@ mod tests {
         let a = VecMem::new(1);
         let a_clone = a.clone();
         let v_ref = a.get_ref::<u8>(0).unwrap();
+        let barrier = Arc::new(Barrier::new(2));
+        let barrier1 = barrier.clone();
+
         v_ref.store(99);
         spawn(move || {
-            sleep(Duration::from_millis(10));
+            barrier1.wait();
             let clone_v_ref = a_clone.get_ref::<u8>(0).unwrap();
             clone_v_ref.store(0);
         });
@@ -1574,6 +1577,7 @@ mod tests {
         // somehow and this helps to ensure the sleep actually happens before the store rather then
         // being reordered by the compiler.
         assert_eq!(v_ref.load(), 99);
+        barrier.wait();
 
         // Granted we could have a machine that manages to perform this many volatile loads in the
         // amount of time the spawned thread sleeps, but the most likely reason the retry limit will