[concurrency-interest] concurrency newbie question
genman at noderunner.net
Tue Jun 23 21:28:57 EDT 2009
On Tue, Jun 23, 2009 at 7:25 AM, Ashley Williams <ashpublic at mac.com> wrote:
> Unfortunately that isn't an option for me, firstly because the code that
> loads and saves this class needs
> to assume a bean-style interface rather than an intermediate Builder class,
> as it is part of a generic library
> that others may use.
> Also I've only included a few of the system wide settings there are
> potentially many more and therefore
> it would be wasteful that somebody who just wants to change one of the
> dozens of settings
> causes a brand new object to be created.
> I'm open to the fact that I'm not yet thinking correctly when it comes to
> concurrency ;) but the settings class
> I have seems to be fundamentally mutable in nature.
In the days before volatile and Atomic variables were commonly used, people
would just simply mark every reader and writer method as synchronized.
And even today, I feel the plain-Jane "synchronized" keyword is fine,
although it appears to lack sophistication as a Java developer. The JCiP
book makes a good argument to continue to use the synchronized keyword since
it's simple to grok.
But at the same time, I wouldn't argue against having immutable objects
either. Allocation and copying is very cheap, and the more immutable objects
you have, the less trouble you have proving a program is correct. Or more
generally, it means less bugs. But on the other hand, having simpler code is
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest