I finally took a quick look at Request and Response. The thing to remember
about volatiles is that there is no practical way to enforce atomicity with
volatiles alone. So lazy initialization checks like this:
public Conditions getConditions() {
if (this.conditions == null)
this.conditions = new Conditions();
return this.conditions;
}
aren't safe. Multiple threads calling getConditions() at around the same
time might each get a different Conditions instance.
Adding synchronization would fix this. You can even use the safe version of
the double-check idiom for lazy initialization of instance fields,
recommended by Josh Bloch:
public Conditions getConditions() {
Conditions c = this.conditions;
if (c == null) {
synchronized (this) {
c = this.conditions;
if (c == null)
this.conditions = c = new Conditions();
}
}
return c;
}
Note that this pattern must be used exactly as above to be worthwhile. (And
the conditions field must still be volatile, or you're back to the broken
double-check idiom!)
Best of all would be to avoid lazy initialization entirely. Are any of those
initializations expensive?
But fixing or removing lazy initialization is only sufficient if there are
no class invariants that involve two volatile fields simultaneously. I
haven't looked hard enough to see if that is the case. If it is, then you
need to synchronize access to the those fields whenever the invariant might
temporarily be invalidated.
--tim
On Tue, Apr 1, 2008 at 3:42 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote:
> Tim Peierls wrote:
>
> > I hate to sound like a broken record, but the Restlet Request and
> > Response classes are not thread-safe, so Restlet cannot yet take *full*
> > advantage of NIO to break out of the thread-per-request paradigm. (There is
> > movement on this front, however, as Rob Heittman pointed out earlier in this
> > thread.)
> >
> I would like to mention that I've completed the work to make Request,
> Response, Representation and all related classes in API, NRE and extensions
> thread safe.
>
> It was mostly a matter of adding the right modifier, either 'volatile' or
> 'final' as there is rarely a need for strong synchronization in those
> classes. Most of the time they are accessed by one thread at a time.
>
> However, I wouldn't mind having expert eyes looking at the result and
> making sure everything is ready to support advanced handling, IO and
> threading scenarios!
>
> Best regards,
> Jerome
>
>
