Hi all, Ok, let's keep track of this task. I've entered:
"Check synchronization needs for lazy inits" http://restlet.tigris.org/issues/show_bug.cgi?id=480 Best regards, Jerome > -----Message d'origine----- > De : Kevin Conaway [mailto:[EMAIL PROTECTED] > Envoyé : samedi 5 avril 2008 23:19 > À : [email protected] > Objet : Re: Evaluating Restlet > > A lot of the lazy initializations seem to be basic > Collections. I don't know of many cases where there is a > truly expensive object that is lazy initialized. > > In my use cases, Request and Response objects do not have > long lifecycles so carrying around a final, empty Collection > here and there might be worth it in relation to possible > concurrency issues > > > On Sat, Apr 5, 2008 at 12:23 PM, Tim Peierls <[EMAIL PROTECTED]> wrote: > > > On Sat, Apr 5, 2008 at 5:07 AM, Jerome Louvel > <[EMAIL PROTECTED]> wrote: > > > 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. > > > OK. At some point it would be great to do some > profiling with and without lazy init to see what effect the > extra object creation has. > > Uh-oh, that probably sounded like volunteering ... > maybe I better retract that comment! :-) > > > > > 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? > > > > No. As long as there is a window in which one thread > can observe the field with a null value before another thread > initializes the field, there is a bug. It might be highly > unlikely to cause trouble in practice, but that just makes > the bug harder to detect when it finally does trigger. > > The complexity of the double-check lazy init idiom is > daunting (to me, anyway), but you're not obliged to use > volatiles. Simple synchronization works, too: > > @GuardedBy("this") private FieldType field; > > public synchronized FieldType getField() { > if (field == null) > field = initialFieldValue(); > return field; > } > > @GuardedBy("this") means that *all* access to the field > is performed in a synchronized (this) {} block (or a > synchronized method). This might be slightly slower than > using volatile on some platform/hardware combinations, but > it's the *only* way to go if you have a class invariant that > involves multiple non-final fields. As I said, I haven't > looked hard to see if that is the case with Request, Response, etc. > > --tim > > > >
