Well, yeah, I did know that it's two distinct locks on two different objects :) I was pretty sure that the outer lock (MethodImplOptions.Synchronized) is both unnecessary and not recommended (since it is locking on publicly available instances). Since I'm near that code, I'll rip those out. On 30 Nov 2009, at 15:45, Ayende Rahien wrote:
> Well, it is locking on two different things, I can't see why you would need > to do this, however. > > On Mon, Nov 30, 2009 at 4:09 PM, Steve Strong <[email protected]> wrote: > (another) quick question: In the various caches used for holding Query > Plans, there's lots of code like this: > > public object this[object key] > { > [MethodImpl(MethodImplOptions.Synchronized)] > get > { > lock (SyncRoot) > { > object result = > softReferenceCache[key]; > if (result != null) > { > strongReferenceCache.Add(key, > result); > } > return result; > } > } > } > > Is there any good reason for the two locks? Seems to me to just be > unnecessary overhead, but I'm perhaps missing something subtle... > > Cheers, > > Steve > >
