Thanks. I think the non decoder stuff is fine to commit, but I'm not sure how we go about selecting a long term solution

src/arch/x86/decoder.cc (Diff revision 1)

You've used Mtx and Mutex as a suffix for a lock. I don't know that we have a particular coding style, but in the places we've used a mutex in the code so far we used mutex, so unless there are any strong objections I vote to stick with that 

Show all issues

src/arch/x86/decoder.cc (Diff revision 1)

There is a 5th option:
A thread-local instCachMap which is probably superior to #1 assuming you have more that one simulated cpu per physical cpu. 
There is shared_lock in c++14 and the implementation is pretty simple based on mutex and condition variables:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html#shared_mutex

Show all issues

Out of curiosity, is there any performance impact for the single-threaded case?

I doubt it is a big issue at this point, but for sake of argument, the random number generation is also not thread safe.