допустим есть сложный объект со ссылками на другие объекты
то если его поместить в lock то он будет полностью (со всеми вложенными объектами)
заблокирован от изменения другими потоками в пределах lock ? 

lock(obj)
{
    //обработка obj
}

Ты неверно понимаешь принцип работы инструкции lock. 
На самом деле она является синтаксической оберткой для вызовов Monitor.Enter(object obj) и Monitor.Exit(object obj) в рамках блоков try-finally. 
Причем данные методы принимают параметром ссылку на объект синхронизаиции.
Важно понимать что объект синхронизации - это не тот объект, доступ к которому ты защищаешь, а точка соприкосновения конкурирующих потоков. 
Попробую привести такую аналогию...
Помнишь игру, в которой все бегают вокруг стула пока музыка играет, а когда музыка прекращается, надо сесть на единственный стул. 
Так вот, обработка защищаемого объекта  - это как раз сидение на стуле и злорадное похихикивание над теми, кто не успел.
А объект синхронизации - это сам стул: с одной стороны без него нельзя, и чтобы выполнять обработку(сидеть и похихикивать) он должен быть, и кроме того он должен быть всем виден, с другой стороны самому стулу глубоко все-равно, он просто присутствует...

Вот примерный вариант использования


p/s. Советую почитать Рихтера (критические секции - это как раз то, чем занимается lock).

Ctrl, я тебя правильно понял: пока не завершится выполнение кода внутри блока лок все обращения к объекту будут становиться в очередь?
а что будет при попытке изменения объектов, ссылки на которые записаны в членах заблокированого объекта?

Нет. Пока не завершиться выполнение блока все остальные будут ждать !в начале блока! пока он не освободиться.

Пример со стулом грамотно и наглядно  показывает, что это не так. В момент когда кто-то сидит на стуле (зашел в секцию lock (стул)) кто-то может его красить, пилить...
Если продолжать аналогию со стулом: нам нужно поменять лампочку. Для этого нужен стул. Если стульев много, то лампочку может закрутить любой, попутно мешая другому. А если он один, то приходиться ждать его, пока не остановится.

И еще раз:

Ctrl, это я все и так знаю, но есть нюансы которые вызывают вопросы
в твоем примере guard выступает в роли объекта синхронизации и действительно 
obj и все его члены блокируются внутри

но если во втором потоке опустить lock то блокировке наступает конец

вот пример в котором все работает как надо


но если в Set0() закоментить lock, то сразу вылетает "Попытка деления на нуль."


на самом деле задача у меня следующая
есть объект, который редактируется в Propertygrid
запускается поток который его должен подрючить, 
во время вздрючки в потоке объект должен быть заблокирован от
изменений в Propertygrid

Добавлено через 5 минут и 23 секунды

как тогда защитить доступ к объекту на время выполнения метода ?

Каждую критическую секцию оборачивать в СВОЙ lock!

ivashkanet,  а как быть с такой задачей ?



 у меня есть только одна идея:
перед запуском потока обработки объекта клонировать его,
т.к. это происходит в одном потоке GUI то пользователь не сможет его
поменять через  Propertygrid в момент клонирования. Поток уже будет работать с клоном

Неплохой и самый быстрый, в плане разработки, вариант.


Если объект твой, то можно создать его синхронизированную версию объекта и ложить в грид именно ее.

 ты имеешь ввиду [Synchronization] атрибут для класса объекта ?

Grambler, нет, я имею ввиду класс-декортатор как это сделано для ArrayList: