Updating resources while avoiding race conditions

I am writing a utility class for a game client. This class has two main functions: connect to a game server and retrieve the current game revision, and retrieve a "recipe", which is basically serialized data containing information unique to a revision number. The specifics of the "recipe" are irrelevant for the purposes of this class.

Because one instance of my application can support multiple game sessions, each on a different thread, I need the public methods in this class to be thread-safe. In particular, I am concerned about race conditions in the forceUpdateRevision, getRevision, and getRevision methods. I made the internal update methods synchronize on a private object to ensure that only a single thread can update at the same time, but I am not sure if that is enough to prevent race conditions in the aforementioned methods. I am also not sure if the volatile modifiers are on the cachedRevision and cachedRecipe fields are needed.

By race condition, I am, for example, referring to two threads invoking the forceUpdateRevision method at slightly different times, and the result of updateRevision is different for both threads. In such a case, I fear undefined behavior. I suppose that one solution could be to synchronize the forceUpdateRevision method entirely, rather than the underlying update methods, but I want to minimize how much I synchronize to avoid locking down the entire class by one method call, since updateRevision and updateRecipe, in principle, are completely independent of each other.

Can someone more experienced with thread-safety and race conditions look at my code and see if it can suffer from possible race condition issues?

I have included the entire source code for the class for completeness, though I reckon analyzing the specifics of the internal update methods are not that useful for my question.

```
public final class Revision {

public static final SocketAddress ADDRESS = new InetSocketAddress("game.server.a

Your two variables cachedRevision and cachedRecipe must only be accessed inside synchronized blocks - anything else is definitely code smell. Careful analysis might prove you right, but take special care.

Marking static shared variables as volatile is good practice. will ensure that the optimiser does not make assumptions that fail when multi-threaded.

I would repeat the tests currently outside the synchronized blocks again inside the synchronized blocks. This, along with the volatile declarations, avoids a possible race condition when two threads arrive at the first test at near enough to the same time. This might be harmless, but then again it might not be...

StackExchange Code Review Q#114257, answer score: 2