The code the author gave is Java, so the hash map is most likely a ConcurrentHashMap, and it's safe to access and modify concurrently. The author's code is simp

The code the author gave is Java, so the hash map is most likely a ConcurrentHashMap, and it's safe to access and modify concurrently. The author's code is simplistic and inefficient, but it won't deadlock, it won't corrupt the hash map, it won't go more than a second past the timeout, and it won't fail to retrieve the data if the other thread sets it in a reasonable amount of time. To me, the smell is not that the author is using the wrong multithreading primitives but that they're using multithreading primitives at all. The first step if they want a better solution (and if the context allows them to rewrite the code in question) is to pick one of the many pre-packaged concurrency abstractions that will be safer and more optimized than 99.99% of programmers could write for themselves. Unless they have an extremely unusual problem, which they almost certainly don't, they don't need to be messing with mutexes and conditions at all. Honestly, judging from the style of the concurrency, I would guess that they're working with 15+ year old legacy code, and it's very possible that there's a bizarre reason they can't fix it.