Hi Tim, Thanks for the suggestion about the safe double-check idiom, very cool. As Request/Response have many optional property and as those are very frequently created objects, I think we should ready try to keep lazy initialization in place.
However, I don't see cases where the Request/Response objects (and dependent objects) would be access by multiple threads *at the same time*, only by different threads at different times if we do async handling or async NIO writing. Could that assumption save us some additional synchronization work? Best regards, Jerome > -----Message d'origine----- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la > part de Tim Peierls > Envoyé : jeudi 3 avril 2008 13:55 > À : [email protected] > Objet : Re: Evaluating Restlet > > 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 > > > > >
