Yes, unfortunately the FxCop/Code-Analysis team hasn't taken the stance that lock(this) is unacceptable... So, as a result, lock(this) doesn't get flagged by the usual "process" and therefore doesn't get the scrutiny it deserves before publication.
It's a shame really; because it can bite a lot of programmers and there's really no overhead to using a private Object for the locking. Which is really where SyncRoot property evolved from. If it were safe to lock (this) SyncRoot wouldn't be that necessary. It's not that String is immutable that makes it a bad idea for locking; it's that is has a weak identity. It has a weak identity, as you mentioned, because of it's other attributes: interning, it can be accessed across AppDomains... Although, immutable classes are more likely to have their reference replaced; which makes them a less than optimal candidate for use in a lock. On Fri, 11 Aug 2006 11:43:56 -0400, =?ISO-8859-1?Q?S=E9bastien_Lorion?= <[EMAIL PROTECTED]> wrote: >Even the lock code snippet in VS 2005 suggests "this" as a default >value. How do they expect people to learn ? > >Btw, locking on a string is not a good idea either because since >strings are immutable, they can be shared/interned, thus they may be >publicly accessible too. > >Sébastien > >On 8/11/06, Peter Ritchie ><[EMAIL PROTECTED]> wrote: >> Some references on what is good to lock and what is bad to lock upon: >> http://msdn2.microsoft.com/en-us/library/ms228970.aspx >> http://msdn2.microsoft.com/en-us/library/c5kehkcz.aspx >> http://haacked.com/archive/2005/04/12/2634.aspx >> >> Yes, it's still fairly common to see lock(this), even with sample code >> from Microsoft; it's just not suggested... =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
