Немного запутанных вещей о замках

Ответ 1

• Объем блокировки в этой ситуации - это отдельный экземпляр самого класса. Это противоречит пересечению всего экземпляра конкретного класса. Вы можете заблокировать все блокированные экземпляры TestThreading, сделав lockThis static. То, что подразумевается под "областью" блокировки: применимо ли оно к одному экземпляру или применимо ко всем экземплярам определенного типа.

• "Блокировка объекта thisObject" просто означает использование этого объекта как объекта, который определяет, находится ли мы в блокировке. Этот термин не предполагает, что мы "заблокировали" объект lockThis. Думаю, ваша оценка здесь правильная. Другие объекты могут все же получить доступ к lockThis из другого потока, но они не смогут обрабатывать код, который окружен блокировкой на этом объекте.

Поскольку мы отвечаем друг другу, здесь немного больше информации:

Давайте рассмотрим аналогию с "комнатой и ключом", описанную выше, и расширьте ее для каждой возможности. У нас есть несколько разных ситуаций:

• статическая функция, статический объект блокировки. Это аналогично наличию одной комнаты с одним ключом.
• функция экземпляра, статический объект блокировки. Это будет похоже на наличие нескольких комнат, которые используют один и тот же ключ... например, как основной ключ.
• функция экземпляра, объект блокировки экземпляра. Это будет похоже на наличие нескольких комнат, каждый из которых имеет собственный ключ... как общежитие или гостиницу.
• статическая функция, объект блокировки экземпляра - невозможно. Вы не можете получить доступ к полю экземпляра из статического контекста.

Надеемся, что в приведенных выше сценариях описывается, как они будут работать вместе.

В ответ на второй ответ

Я не уверен, что вы подразумеваете под TestThreading. Функция не может получить доступ к lockThis?!

Он не может получить доступ к полезному lockThis. Статическая блокировка метода на экземпляре, который отбрасывается при завершении блокировки, бесполезна. В сценарии, который вы настраиваете, каждый раз, когда к двери приближается, замок "отдает" новый ключ и говорит "хорошо, я принимаю ключ, который я только что дал вам... вы можете войти". В этой ситуации он слишком осторожно защищает "комнату", предоставляя каждому доступ, когда захочет. Другими словами, нет причин даже иметь оператор блокировки во втором примере. Он, как и комната, имеет динамически увеличивающееся количество дверей, которое используется только один раз, и на нем есть ключ. Бесконечное количество людей может войти, когда захочет. Нет никакой разницы между вашим кодом и следующим, действительно (есть, но это так, что вы можете надеяться получить концепцию:

public class TestThreading
{
    private object lockThis = new object();

    public static void Function() 
    {
        lockThis = new object();
        lock (lockThis)
        {
            // access something   
        }
    }
}

То, что я сделал в этом примере выше, в основном выбрасывает и снова запирает замок прямо перед тем, как использовать его в дверях. Это не полезно. Вы правы, синхронизация потоков не будет, и в этом смысле я бы сказал, что код действительно не работает вообще, так как вся точка блокировки - синхронизация потоков.

если lockThis был статическим, тогда все Экземпляры TestThread в той же комнате (aka lock), хотя TestThread.Function не является статическим. Предполагая, что я это правильно понимаю теперь, тогда термин блокировка ссылается к ключу (таким образом, блокировка не относится к комната?!), используемый для открытия двери?

Нет, если функция статическая, то все экземпляры TestThread будут использовать одну и ту же комнату, если lockThis является статическим, тогда все экземпляры TestThread будут использовать один и тот же ключ.

lock (key)
{
   // room
}

Комната - это код, который выполняется внутри замка, а не самого объекта lockThis, который просто является ключом.

Таким образом, если мы предположим, что lockThis static и TestThread.Function не статический, затем область ключа/блокировки все экземпляры TestThread, которые означает, что все экземпляры TestThread делиться одним и тем же ключом, и, таким образом, когда один Экземпляр TestThread открывает дверь его комната с использованием этого ключа, другая экземпляры не смогут открыть двери в свои комнаты до первого экземпляр выпускает этот ключ?

Да.

Ответ 2

Чтобы проиллюстрировать различия в блокировке статических или нестатических объектов, рассмотрите:

public class TestThreading
{
    private object lockThis = new object();
    private static object lockStatic = new object();
    private Stream UIStream;
    private List<int> calcStuff;

    public void DoStuff1()
    {
        lock (lockThis)
        {
            // Do stuff with calcStuff that is unique to this instance
            // it okay to have different instances calculating their own stuff
        }
    }

    public void DoStuff2()
    {
        lock (lockStatic)
        {
            // Do stuff with the UI,
            // which you don't want multiple threads accessing at once
        }
    }
}

особенно в такой ситуации, как

var A = new TestThreading();
var B = new TestThreading();

((Action)(A.DoStuff1)).BeginInvoke(null,null); // These can go concurrently
((Action)(B.DoStuff1)).BeginInvoke(null,null); // just fine

((Action)(A.DoStuff1)).BeginInvoke(null,null); // These will have to wait
((Action)(A.DoStuff1)).BeginInvoke(null,null);

((Action)(A.DoStuff2)).BeginInvoke(null,null); // These will have to wait
((Action)(B.DoStuff2)).BeginInvoke(null,null);

Ответ 3

То, о чем говорится в этом параграфе, - это то, что код имеет возможность использовать блокировку, а не как долго удерживается блокировка (которую эта статья называется длительностью блокировки).

Ответ 4

Ответ Дэвида Мортона кажется мне правильным, но для большей справки см. этот сайт: Threading in С# Это отличный ресурс для всех вещи, нарезанные в С#, включая примеры того, что не делать в нескольких случаях. Очень ясная ИМО.

Ответ 5

a) Поскольку каждый объект класса TestThreading будет иметь собственный объект "lockThis", только этот отдельный объект будет находиться в области блокировки b/c только в том, что отдельный объект может даже ссылаться на "lockThis" (b/c это личное)

b) Нет, это означает, что поскольку объект TestThreading, вызывающий блокировку, является единственным объектом, который может "блокировать" критический регион (опять же, b/c он является закрытым), "блокировка блокировки объекта" означает, что вы блокируете объект TestThreading с использованием частного типа привязки lockThis.

Например, если вместо этого вы написали это:

public class TestThreading
 {
     // private System.Object lockThis = new System.Object();

     public void Function()
     {

         lock (this)
         {
            // Access thread-sensitive resources.
         }
     }
  }

Не только отдельный объект сможет заблокировать объект с помощью метода Function, КАЖДЫЙ КЛАСС, КОТОРЫЙ СЛУЧАЙТЕ, что используемый объект TestThreading может заблокировать с помощью метода Function, b/c объект TestThreading предположительно будет по меньшей мере "внутренний", если не "общедоступный".