« Return to Thread: concurrency issue with Factory?

Re: concurrency issue with Factory?

by tpeierls :: Rate this Message:

I don't know enough about how the Factory class is used, but if there's any possibility that a thread other than the one that calls setBuilder will try to read the value of the builder field, then you need to either make builder volatile or guard it with some sort of synchronization. Otherwise that reader thread might see a null value even if the read happens a long time after the call to setBuilder.

I only noticed this because Patrick Lightbody mentioned the existence of ServerContextFactory.get() with no arguments -- something I hadn't known about -- and I wanted to see how it worked.

--tim

Joe Walker-3 wrote:

On Sun, Aug 31, 2008 at 5:34 PM, Tim Peierls <tim@peierls.net> wrote:

> I just stumbled across the new Factory class in
> org.directwebremoting.extend and noticed a couple of problems. The very
> minor one is that it seems to have been generified from code that was
> specific to JsonParser, e.g., get(ServletContext) is documented as returning
> "The current JsonParser".
>

Yeah - the JsonParser was the point were my happiness to cut and paste
broke, and I generalized it. Thanks.

> The more interesting one is that the builder field (and thus the entire
> class) is not safe for concurrent access. It might be that instances of
> Factory are meant to be confined to a single thread, in which case the
> documentation should reflect that. If not, though, builder should be made a
> volatile or be guarded by a lock.
>

Once again I'm slightly humbled and scared by the frequency with which you
find these.
I've added to the documentation that the function should only be called
while the context is starting up.
I believe that the setter should be called first, once only, and from then
on it will only be read.

Joe.

« Return to Thread: concurrency issue with Factory?