Noob synchronization question - updating static member data reference
I have a class with some static member data that is used throughout the code. Nothing modifies it so I haven't had to worry about synchronization. However, now I want to be able to change it at run-time and I'm not sure what all needs to be done. Here is an example of the type of thing I'm working with:
publicclass MyClass
{
privatestatic configData;
public MyClass()
{
configData =new ConfigData();// Loads it all up from a file
}
publicstatic String getConfigVal(String key)
{
return configData.getVal(key);
}
// METHOD I WANT TO ADD
publicsynchronizedvoid reloadConfig()
{
configData =new ConfigData();
}
}
I know I need to synchronize the method that actually updates the config data but I'm not sure if this will cause problems for anything that reads from it. It is not a problem for us if two threads (or even the same thread with two calls) gets different values for the same key.Any advice?
Thanks,
Paco
Message was edited by:
MePaco
[1795 byte] By [
MePacoa] at [2007-11-27 7:50:57]
# 1
> configData = new ConfigData(); // Loads it all
> up from a file
Setting a static member variable at object construction is a bad idea.
In any case, you should syncrhonize all access to that variable. I think that starting with 1.5, the JMM rules were changed such that if the only changes you're making are constructing a new object, you're safe even with out syncing, but a) I'm not that familiar with the new JMM, so I'm not sure, and b) if there's any chance that code will be run in a pre-1.5 environment, you MUST sync.
jverda at 2007-7-12 19:32:02 >
# 2
Thanks for the reply.
> Setting a static member variable at object construction is a bad idea.
Because of the way the class is used I'm guaranteed that only one will ever be instantiated so I think I'm safe, but please tell me if I'm wrong or if there are other reasons to worry.
I'm trying to avoid synchronizing all accesses because many many threads will be reading from the object so I don't want to slow that access down if possible. Also, it will rarely be reloaded so I might just go with what you think and do some experimentation before going live with it.
This will only be used in 1.5 and eventually 1.6 environments so hopefully you are right. I'm going to do some more digging and will post if I find out for sure one way or another. If anyone else knows, please enlighten me.
# 3
> Thanks for the reply.
>
> > Setting a static member variable at object
> construction is a bad idea.
>
> Because of the way the class is used I'm guaranteed
> that only one will ever be instantiated
Then make the variable non-static.
> I'm trying to avoid synchronizing all accesses
> because many many threads will be reading from the
> object so I don't want to slow that access down if
> possible. Also, it will rarely be reloaded so I
> might just go with what you think and do some
> experimentation before going live with it.
If you need synchronization, you need it. You can't write your program hoping that the case that will cause it to behave incorrectly will be rare.
jverda at 2007-7-12 19:32:02 >
# 4
> Then make the variable non-static.
Please understand that the code I'm working on is much more complex than the simple example I gave. I'm working under a framework that doesn't give me a lot of good options for passing around instantiated objects. Instead, I decided the easiest solution to make the functionality accessible in other classes was to make the methods static, necessitating that the variable be static as well.
> If you need synchronization, you need it. You can't write your program hoping that the case that will cause it to behave incorrectly will be rare.
Yes, I understand that. Because none of my methods alter the data in the object, inconsistent data between calls is not a problem, and I simply want to replace the entire object I thought it might be okay to do it without synchronization. I'm only here because I wanted to know if anyone saw any problems that I might have overlooked. You said yourself that you think it might be fine. I'm not going to just do it and hope it works. I just wanted some feedback from people more experienced with it than me.
# 5
> > Then make the variable non-static.
>
> Please understand that the code I'm working on is
> much more complex than the simple example I gave.
> I'm working under a framework that doesn't give me a
> lot of good options for passing around instantiated
> objects.
I have a hard time believing that's relevant. If only one of your object will ever be created, make it a singleton and make that member variable non-static. Or else keep the variable static and make all the methods staitc.
> Instead, I decided the easiest solution to
> make the functionality accessible in other classes
> was to make the methods static, necessitating that
> the variable be static as well.
Then why even have a public constructor? Why instantiate the object at all?
> Yes, I understand that. Because none of my methods
> alter the data in the object, inconsistent data
> between calls is not a problem, and I simply want to
> replace the entire object I thought it might be okay
> to do it without synchronization.
If the only time the state of the object is in flux is during construction, then I think that with the new JMM in 1.5 it's safe not to synchronize. (Don't take my word for it though.) Still, I wouldn't assume that syncing will pose a performance problem. I'd test and measure.
jverda at 2007-7-12 19:32:02 >
