From 5051524d40b79ee6731987ef2ae564a7f8685d88 Mon Sep 17 00:00:00 2001
From: greg <greg7mdp@gmail.com>
Date: Sat, 9 Mar 2019 13:09:27 -0500
Subject: [PATCH] wip

---
 README.md                                           |   6 +++++-
 img/{flat_pat_mutex_4.PNG => flat_par_mutex_4.PNG}  | Bin
 img/{flat_pat_mutex_5.PNG => flat_par_mutex_5.PNG}  | Bin
 ...mutex_5_speed.PNG => flat_par_mutex_5_speed.PNG} | Bin
 ...mutex_6_speed.PNG => flat_par_mutex_6_speed.PNG} | Bin
 pdf/parallel_hashmap.html                           |   5 ++++-
 6 files changed, 9 insertions(+), 2 deletions(-)
 rename img/{flat_pat_mutex_4.PNG => flat_par_mutex_4.PNG} (100%)
 rename img/{flat_pat_mutex_5.PNG => flat_par_mutex_5.PNG} (100%)
 rename img/{flat_pat_mutex_5_speed.PNG => flat_par_mutex_5_speed.PNG} (100%)
 rename img/{flat_pat_mutex_6_speed.PNG => flat_par_mutex_6_speed.PNG} (100%)

diff --git a/README.md b/README.md
index 1e562ba..c7b9b5f 100644
--- a/README.md
+++ b/README.md
@@ -204,10 +204,14 @@ template <class K, class V,
 class parallel_flat_hash_map;
 ```
 
-Let's see what result we get for the insertion of random values from multiple threads, however this time we modify the code so that each thread can insert variables in any submap (no pre-selection). 
+Let's see what result we get for the insertion of random values from multiple threads, however this time we create a parallel_hash_map with internal locking, and modify the code so that each thread can insert values in any submap (no pre-selection). 
 
 ![no_preselection](https://github.com/greg7mdp/parallel-hashmap/blob/master/img/no_preselection.PNG?raw=true)
 
+
+
+![flat_par_mutex_4](https://github.com/greg7mdp/parallel-hashmap/blob/master/img/flat_par_mutex_4.PNG?raw=true)
+
 ### In Conclusion
 
 We have seen that the novel parallel hashmap approach, used within a single thread,  provides significant space advantages, with a very minimal time penalty. When used in a multi-thread context, the parallel hashmap still provides a significant space benefit, in addition to a consequential time benefit by drastically reducing (or even eliminating) lock contention when accessing the parallel hashmap.
diff --git a/img/flat_pat_mutex_4.PNG b/img/flat_par_mutex_4.PNG
similarity index 100%
rename from img/flat_pat_mutex_4.PNG
rename to img/flat_par_mutex_4.PNG
diff --git a/img/flat_pat_mutex_5.PNG b/img/flat_par_mutex_5.PNG
similarity index 100%
rename from img/flat_pat_mutex_5.PNG
rename to img/flat_par_mutex_5.PNG
diff --git a/img/flat_pat_mutex_5_speed.PNG b/img/flat_par_mutex_5_speed.PNG
similarity index 100%
rename from img/flat_pat_mutex_5_speed.PNG
rename to img/flat_par_mutex_5_speed.PNG
diff --git a/img/flat_pat_mutex_6_speed.PNG b/img/flat_par_mutex_6_speed.PNG
similarity index 100%
rename from img/flat_pat_mutex_6_speed.PNG
rename to img/flat_par_mutex_6_speed.PNG
diff --git a/pdf/parallel_hashmap.html b/pdf/parallel_hashmap.html
index ca79f19..6326734 100644
--- a/pdf/parallel_hashmap.html
+++ b/pdf/parallel_hashmap.html
@@ -227,7 +227,7 @@
 <p>Still, this is a pretty good result, we are now inserting values into our parallel_hash_map three times faster than we were able to do using the <em>flat_hash_map</em>, while using a lower memory ceiling.</p>
 <h3 id="using-the-intrinsic-parallelism-of-the-parallel_hash_map-with-internal-mutexes">Using the intrinsic parallelism of the parallel_hash_map with internal mutexes</h3>
 <p>It may not be practical to add logic into your program to ensure you use different internal submaps from each thread. Still, locking the whole parallel_hash_map for each access would forego taking advantage of its intrinsic parallelism.</p>
-<p>For that reason, the parallel_hash_map provides optional internal locking using the <code>absl::Mutex</code> (the default template parameter is <code>absl::NullMutex</code>, which does no locking and doesn't have any extra size cost). When selecting <code>absl::Mutex</code>, one mutex is created for each internal submap at a cost of 8 bytes per submap.</p>
+<p>For that reason, the parallel_hash_map can provide internal locking using the <code>absl::Mutex</code> (the default template parameter is <code>absl::NullMutex</code>, which does no locking and has no size cost). When selecting <code>absl::Mutex</code>, one mutex is created for each internal submap at a cost of 8 bytes per submap.</p>
 <table>
 <thead>
 <tr class="header">
@@ -268,6 +268,9 @@
           class Mutex     = absl::NullMutex&gt;   // use absl::Mutex to enable internal locks
 class parallel_flat_hash_map;
 </code></pre>
+<p>Let's see what result we get for the insertion of random values from multiple threads, however this time we create a parallel_hash_map with internal locking, and modify the code so that each thread can insert values in any submap (no pre-selection).</p>
+<p><img src="https://github.com/greg7mdp/parallel-hashmap/blob/master/img/no_preselection.PNG?raw=true" alt="no_preselection" /></p>
+<p><img src="https://github.com/greg7mdp/parallel-hashmap/blob/master/img/flat_par_mutex_4.PNG?raw=true" alt="flat_par_mutex_4" /></p>
 <h3 id="in-conclusion">In Conclusion</h3>
 <p>We have seen that the novel parallel hashmap approach, used within a single thread, provides significant space advantages, with a very minimal time penalty. When used in a multi-thread context, the parallel hashmap still provides a significant space benefit, in addition to a consequential time benefit by drastically reducing (or even eliminating) lock contention when accessing the parallel hashmap.</p>
 <h3 id="thanks">Thanks</h3>