good and simple introduction to mutlithreading

[109]

http://msdn.microsoft.com/en-us/magazine/cc163744.aspx

For a lock to provide mutual exclusion for a region of memory, no writes to that memory can occur without entering the same lock. In a properly designed program, associated with every lock is a region of memory for which it provides mutual exclusion. Unfortunately, there is no obvious artifact of the code that makes this association clear, and yet this information is absolutely critical for anyone reasoning about the multithreaded behavior of the program.

what would be the ideal syntax? what comes to mind is

object myLock = new object();
[Protected(myLock)] MyState myState;

x-posted

Comments

[109.livejournal.com]

во-первых, читай мой ответ msh.

во-вторых, предложенный синтаксис решает не проблему собственно локинга, а проблему "there is no obvious artifact of the code that makes this association clear". то есть, после добавления такого атрибута компилятор (если может), или рантайм (если компилятор не может) должны бросать ошибку типа "attempt to access shared resource myState when myLock is not acquired".

зачем отдельный lock, про это много литературы написано, в том числе и по ссылке. но если девелопер считает, что он знает лучше, он может написать [Protected(myState)] MyState myState; или там просто [Protected] myState, что то же самое, что, как ты написал, [Synchronized] myState, ну или так, как Антон написал, как в джаве делается.

[faceted-jacinth.livejournal.com]

Ну, может быть, может быть.

Правда, есть ряд сложностей. Во-первых, такая запись может вызвать Ложное Чувство Защищённости™. Во-вторых, далеко не всегда ресурс == один объект. А так -- да, в принципе довольно правильная штука.

[109.livejournal.com]

далеко не всегда ресурс == один объект.

object myLock = new object();
[Protected(myLock)] MyState myState;
[Protected(myLock)] MyState2 myState2;

Ложное Чувство Защищённости

да, примерно так же, как automatic memory management вызывает ложное чувство защищённости от memory leaks.

[faceted-jacinth.livejournal.com]

Я о том, что после этого компилятор будет совершенно удовлетворён, если ты сделаешь
lock(myLock)
{
tmp = myState;
}

lock(myLock)
{
myState2 += tmp;
}

Тогда как на самом деле всё должно было происходить внутри одного и того же лока, например. Или не должно. Но компилятор больше не ругается. Вдобавок этой штукой, видимо, переменные, а не объекты защищаются, поэтому ссылка может утечь и компилятор ничего не скажет.


Но в целом да, идея вполне правильная. Её даже наверное можно реализовать сторонней тулзой (или на базе fxCop'a какого-нибудь).

[109.livejournal.com]

ну да, during compile-time, очевидно, только переменные можно защитить. а в рантайме можно и объекты. хотя я с утра плохо соображаю. например, не могу понять, что такого thread-unsafe в коде, который ты написал.

[faceted-jacinth.livejournal.com]

Объекты нельзя защищать потому что совершенно непонятна семантика - насколько глубоко защищать-то. Поля объектов ведь тоже содержат объекты иногда, а то и целые коллекции.

А кодом я, видимо, что-то имел в виду, но сам не пойму уже. Неважно, в общем смысл понятен, наверное.

[109.livejournal.com]

в смысле, насколько глубоко? точно так же, как Synchronized защищает, непосредственные свойства и методы объекта. эдак ведь тоже можно вытащить Synchronized reference type и менять его сколько влезет не-thread-safe способом.

смысл твоего кода неожиданно стал понятен :)
ну да, эта проблема существует и сейчас, никуда не девается, но при чём здесь? повторить, какую проблему решает предложенный мной синтаксис? :)