I would seriously re-evaluate the strategy of using multiple threads in this way.   If both of them have to update the same shared hash, then it is fairly certain that the two threads will, in fact, be running lock-step most of the time.   (Even in the presence of multiple CPUs, the two threads are in a mutual-exclusion state with respect to one another.   Therefore, why have multiple threads?)

It would probably be much more efficient to simply have one thread doing this, even if it has nothing else to do.   A queue can be used to give the thread requests to do whatever it does.

I often see a multi-threaded scheme used when a program has to accept inputs from multiple sources.   A new thread is created to service each source.   (In extremely bad examples, a new thread is sometimes created to service each request, in what I call “the flaming arrow approach.”)   In practice, it is probably better to have one thread that does nothing but to listen for inputs from all of these sources (at once), and which then queues the requests for processing by (one or more) service threads.   The completed outputs are then placed onto another queue, for delivery by (one...) output thread.