[concurrency-interest] Basic thread safety question: final/volatile/synchronized fields
Dhanji R. Prasanna
dhanji at gmail.com
Wed Dec 20 20:03:09 EST 2006
On 12/21/06, Brian Goetz <brian at quiotix.com> wrote:
> > Ah, good point. An external class can provide the thread safety
> > (client-side locking I think was the JCiP term?).
> In this case it would be called confinement -- the Foo is confined in
> the Moo, and Moo provides the right synchronization.
> > But, good to know I understand correctly. The reason I questioned
> > myself was that I've seen precious few thread safe classes. I've rarely,
> > if ever, seen much attention paid to making sure each instance field is
> > properly protected. A few assessors might be synchronized, but the
> > thread-safety considerations are ad-hoc at best.
> Sadly, yes.
Is it really? I would consider most code (to be very general about it) to
be service code (frameworks, sdks, Business APis, Daos, etc.), and it should
be upto clients to synchronize correctly.
For one specific instance: I'd much more readily use
java.util.ArrayListthan Vector even though the latter is threadsafe
and the former is not
(apart from the other benefits of the Java Collections Framework), and
synchronize in my client code.
And these days most code runs in some kind of container which provides
threading out of the box--whether it be EJB, a servlet container, Swing
workers or some abstraction of j.u.c TPEs.
I agree that sometimes client code is not synchronized properly (or at all),
but I find more often that service code is unnecessarily and improprietously
synchronized which can cause far greater headaches and portability issues.
Do you agree?
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest