SyncRoot模式有什么用？
我正在阅读描述SyncRoot模式的ac＃书。 表明
void doThis() { lock(this){ ... } } void doThat() { lock(this){ ... } } 并与SyncRoot模式进行比较：
object syncRoot = new object(); void doThis() { lock(syncRoot ){ ... } } void doThat() { lock(syncRoot){ ... } }
不过，我不太了解这里的区别。 似乎在两种情况下，两种方法一次只能由一个线程访问。
本书描述了…因为实例的对象也可以用于从外部进行同步访问，并且不能控制这个表格的类本身，所以可以使用SyncRoot模式 Eh？ “实例的对象”？
谁能告诉我上面两种方法的区别？
提前致谢
如果你有一个内部的数据结构，你想阻止multithreading同时访问，你应该始终确保你locking的对象不公开。
这背后的原因是一个公共对象可以被任何人locking，因此你可以创build死锁，因为你不完全控制locking模式。
这意味着lockingthis不是一个选项，因为任何人都可以locking该对象。 同样，你不应该locking你暴露给外部世界的东西。
这意味着最好的解决scheme是使用一个内部对象，因此小技巧就是使用Object 。
locking数据结构是您真正需要完全控制的东西，否则您可能会设置死锁的场景，这可能会遇到问题。
这里是一个例子：
class ILockMySelf { public void doThat() { lock (this) { // Don't actually need anything here. // In this example this will never be reached. } } } class WeveGotAProblem { ILockMySelf anObjectIShouldntUseToLock = new ILockMySelf(); public void doThis() { lock (anObjectIShouldntUseToLock) { // doThat will wait for the lock to be released to finish the thread var thread = new Thread(x => anObjectIShouldntUseToLock.doThat()); thread.Start(); // doThis will wait for the thread to finish to release the lock thread.Join(); } } }
您会看到第二个类可以在locking语句中使用第一个类的实例。 这导致了这个例子中的僵局。
正确的SyncRoot实现是：
object syncRoot = new object(); void doThis() { lock(syncRoot ){ ... } } void doThat() { lock(syncRoot ){ ... } }
由于syncRoot是一个私有字段，因此您不必担心外部使用该对象。
这里还有一个与这个主题有关的有趣的事情：
SyncRoot集合上的可疑值（由Brad Adams撰写） ：
您会注意到System.Collections中许多集合上的SyncRoot属性。 回想起来，我认为这个属性是一个错误。 我团队的程序pipe理员Krzysztof Cwalina刚刚给了我一些想法，为什么这么说 – 我同意他的看法：
我们发现基于SyncRoot的同步API在大多数情况下都不够灵活。 API允许线程安全地访问集合的单个成员。 问题是有很多情况下，你需要locking多个操作（例如删除一个项目，并添加另一个）。 换句话说，它通常是使用一个集合的代码，它希望select（并且实际上可以实现）正确的同步策略，而不是集合本身。 我们发现SyncRoot实际上很less使用，在使用的时候，实际上并没有增加太多价值。 在不使用的情况下，对ICollection的实施者来说只是一个烦恼。
放心吧，我们不会因为构build这些集合的通用版本而犯同样的错误
这种模式的实际目的是实现与包装层次结构的正确同步。
例如，如果类WrapperA包装了ClassThanNeedsToBeSynced的一个实例，并且类WrapperB包装了ClassThanNeedsToBeSynced的同一个实例，则无法lockingWrapperA或WrapperB，因为如果lockingWrapperA，则WrappedB上的locking不会等待。 为此，您必须lockingwrapperAInst.SyncRoot和wrapperBInst.SyncRoot，它将locking委托给ClassThanNeedsToBeSynced的一个。
例：
public interface ISynchronized { object SyncRoot { get; } } public class SynchronizationCriticalClass : ISynchronized { public object SyncRoot { // you can return this, because this class wraps nothing. get { return this; } } } public class WrapperA : ISynchronized { ISynchronized subClass; public WrapperA(ISynchronized subClass) { this.subClass = subClass; } public object SyncRoot { // you should return SyncRoot of underlying class. get { return subClass.SyncRoot; } } } public class WrapperB : ISynchronized { ISynchronized subClass; public WrapperB(ISynchronized subClass) { this.subClass = subClass; } public object SyncRoot { // you should return SyncRoot of underlying class. get { return subClass.SyncRoot; } } } // Run class MainClass { delegate void DoSomethingAsyncDelegate(ISynchronized obj); public static void Main(string[] args) { SynchronizationCriticalClass rootClass = new SynchronizationCriticalClass(); WrapperA wrapperA = new WrapperA(rootClass); WrapperB wrapperB = new WrapperB(rootClass); // Do some async work with them to test synchronization. //Works good. DoSomethingAsyncDelegate work = new DoSomethingAsyncDelegate(DoSomethingAsyncCorrectly); work.BeginInvoke(wrapperA, null, null); work.BeginInvoke(wrapperB, null, null); // Works wrong. work = new DoSomethingAsyncDelegate(DoSomethingAsyncIncorrectly); work.BeginInvoke(wrapperA, null, null); work.BeginInvoke(wrapperB, null, null); } static void DoSomethingAsyncCorrectly(ISynchronized obj) { lock (obj.SyncRoot) { // Do something with obj } } // This works wrong! obj is locked but not the underlaying object! static void DoSomethingAsyncIncorrectly(ISynchronized obj) { lock (obj) { // Do something with obj } } }
看这个 Jeff Richter的文章。 更具体地说，这个例子certificatelocking“this”会导致死锁：
using System; using System.Threading; class App { static void Main() { // Construct an instance of the App object App a = new App(); // This malicious code enters a lock on // the object but never exits the lock Monitor.Enter(a); // For demonstration purposes, let's release the // root to this object and force a garbage collection a = null; GC.Collect(); // For demonstration purposes, wait until all Finalize // methods have completed their execution - deadlock! GC.WaitForPendingFinalizers(); // We never get to the line of code below! Console.WriteLine("Leaving Main"); } // This is the App type's Finalize method ~App() { // For demonstration purposes, have the CLR's // Finalizer thread attempt to lock the object. // NOTE: Since the Main thread owns the lock, // the Finalizer thread is deadlocked! lock (this) { // Pretend to do something in here... } } }
另一个具体例子：
class Program { public class Test { public string DoThis() { lock (this) { return "got it!"; } } } public delegate string Something(); static void Main(string[] args) { var test = new Test(); Something call = test.DoThis; //Holding lock from _outside_ the class IAsyncResult async; lock (test) { //Calling method on another thread. async = call.BeginInvoke(null, null); } async.AsyncWaitHandle.WaitOne(); string result = call.EndInvoke(async); lock (test) { async = call.BeginInvoke(null, null); async.AsyncWaitHandle.WaitOne(); } result = call.EndInvoke(async); } }
在这个例子中，第一个调用会成功，但是如果你在debugging器中跟踪，DoSomething的调用将被阻塞，直到释放锁。 第二个调用会死锁，因为主线程正在testing监视器锁。
问题是Main可以locking对象实例，这意味着它可以让实例不做任何对象认为应该同步的事情。 关键是对象本身知道什么需要locking，而外部的干扰只是要求麻烦。 这就是为什么具有私有成员variables的模式，您可以专门用于同步，而不必担心外部干扰。
同样的静态模式也是如此：
class Program { public static class Test { public static string DoThis() { lock (typeof(Test)) { return "got it!"; } } } public delegate string Something(); static void Main(string[] args) { Something call =Test.DoThis; //Holding lock from _outside_ the class IAsyncResult async; lock (typeof(Test)) { //Calling method on another thread. async = call.BeginInvoke(null, null); } async.AsyncWaitHandle.WaitOne(); string result = call.EndInvoke(async); lock (typeof(Test)) { async = call.BeginInvoke(null, null); async.AsyncWaitHandle.WaitOne(); } result = call.EndInvoke(async); } }
使用私有静态对象来同步，而不是types。
