Добрый день,

в продолжение этой темы lock(this) — почему плохо? появился дополнительный вопрос. На просторах интернета был найден пример (воспроизвожу по памяти, но вроде бы ничего не напутал):

public class A : B
{

    public IReadOnlyList<int> Foo { get; set;}

    public int Bar { get; set; }

    public A()
    {
        this.Init(this);
    }
}

public abstract class B
{
    private A a;

    protected void Init(A a)
    {
        this.a = a;
    }

    public void Update(IEnumerable<int> foo, int bar)
    {
        lock(this.a)
        {
            this.a.Foo = foo;
            this.a.Bar = bar;
        }
    }
}

Вопросы:

1. lock(this.a) в данном случае эквивалентен lock(this) со всеми вытекающими последствиями?
2. на ваш взгляд имеет ли подобный вариант наследования право на жизнь — спрашиваю, потому что мне интуитивно не нравится такая конструкция, но сформулировать, что именно мне не нравится, я не могу.

PS продолжать тот топик не стал, вроде бы вопрос другого характера, если поступил не правильно извиняюсь.

Здравствуйте, RQ, Вы писали:

RQ>Вопросы:

RQ>1. lock(this.a) в данном случае эквивалентен lock(this) со всеми вытекающими последствиями?
RQ>2. на ваш взгляд имеет ли подобный вариант наследования право на жизнь — спрашиваю, потому что мне интуитивно не нравится такая конструкция, но сформулировать, что именно мне не нравится, я не могу.

RQ>PS продолжать тот топик не стал, вроде бы вопрос другого характера, если поступил не правильно извиняюсь.

This указывает на текущий экземпляр класса и не важно в коде базового класса или подкласса.

 protected void Init(A a)
        {
            Console.WriteLine(this==a);
            this.a = a;
        }

Выводит true.

Здравствуйте, RQ, Вы писали

RQ>Вопросы:

RQ>1. lock(this.a) в данном случае эквивалентен lock(this) со всеми вытекающими последствиями?

Примерно. Блокироваться надо на специально выделенный объект. A таковым не выглядит.

RQ>2. на ваш взгляд имеет ли подобный вариант наследования право на жизнь — спрашиваю, потому что мне интуитивно не нравится такая конструкция, но сформулировать, что именно мне не нравится, я не могу.

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

RQ>PS продолжать тот топик не стал, вроде бы вопрос другого характера, если поступил не правильно извиняюсь.

RQ>1. lock(this.a) в данном случае эквивалентен lock(this) со всеми вытекающими последствиями?
Нельзя лочиться на публичный объект (lock(this)), потому что это чревато дедлоком.

RQ>2. на ваш взгляд имеет ли подобный вариант наследования право на жизнь — спрашиваю, потому что мне интуитивно не нравится такая конструкция, но сформулировать, что именно мне не нравится, я не могу.
Если бы знать, зачем это.

Здравствуйте, yenik, Вы писали:

Y>Если бы знать, зачем это.

На сколько я могу понять, мотив — вынесение логики из наследника в родитель, с учетом того, что логика взаимодействует с полями наследника.

Здравствуйте, RQ, Вы писали:

RQ>На сколько я могу понять, мотив — вынесение логики из наследника в родитель, с учетом того, что логика взаимодействует с полями наследника.

Тут что сову об пень, что пнём по сове — шансы отхватить deadlock не сильно уменьшились.

Нужна возможность расшарить ресурс между несколькими потоками и нет возможности спрятать ресурс за object pool (как с DbConnection сделано) — оборачивайте в RWLockSlim или заведите отдельный тип-заглушку LockKey и делайте блокировки на его экземплярах.

Здравствуйте, RQ, Вы писали:

Sinix написал зачем — что бы не поймать deadlock.
TK написал как — надо лочить специальный объект

Добавлю — если лочить только недоступные извне объекты, то можно доказать что deadlock не будет никогда, а если нарушить запрет, то нельзя.

S>или заведите отдельный тип-заглушку LockKey и делайте блокировки на его экземплярах.
Обычный Object сойдет.

Здравствуйте, namespace, Вы писали:

S>>или заведите отдельный тип-заглушку LockKey и делайте блокировки на его экземплярах.
N>Обычный Object сойдет.

Не, если делать на отстань, то может и сойдёт. А если держать планку, то имеем

public object SomeResourceLockLey => ...

// vs

public LockKey SomeResourceLockLey => ...

Второе вызывает на порядок меньше вопросов, особенно если в XML doc всё расписано.

S>

S>public object SomeResourceLockLey => ...

S>// vs

S>public LockKey SomeResourceLockLey => ...
S>

S>Второе вызывает на порядок меньше вопросов, особенно если в XML doc всё расписано.
Ну да, если делать его публичным
Но лично у меня больше вопросов вызовет класс, в котором нет кода.

Здравствуйте, namespace, Вы писали:

N>Но лично у меня больше вопросов вызовет класс, в котором нет кода.

Зато его легко переиспользовать.