Дискуссии о C#/.NET на русском

4:32 AM

@VladD ну это просто пример такого класса нужен.

9:22 AM

@vitidev Ну например:

public class ConnectTask : TaskWithSession
{
    public ConnectTask(Engine engine) : base("Connect", engine, ConnectTaskProperties.Empty()) { }

    public override async Task Perform(CancellationToken ct, IProgress<double> progress)
    {
        await engine.RedirectTo();
        try
        {
            await Connect(ct);
            State = Procedure.Status.Succeeded;
        }
        catch (TaskCanceledException)
        {
            State = global::Procedure.Status.Aborted;
            throw;

(убрал лишнее из класса)

Ruslan_K

9:34 AM

vlad

Foggy Finder

9:57 AM

@Ruslan_K чтобы обратиться к участнику нужно поставить символ собачки перед ником, например: @Foggy

@VladD ^

VladD

@FoggyFinder Jawohl!

@Ruslan_K Да?

Ruslan_K

@FoggyFinder Спасибо

@VladD хотел проконсультироваться по wpf но уже разобрался, спасибо :)

Foggy Finder

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

VladD

@Ruslan_K А, ну хорошо, что разобрались!

Foggy Finder

>
- Можно спросить?
[5 минут]
- Можно
[5 минут]
- А мне уже не нужно
- Но в чем же дело было?
[участник ушел]

vitidev

2:37 PM

@VladD вот await engine.RedirectTo(); внутри методов не позволяет выполнить в другом потоке, но я не вижу чтения обычных свойств извне

VladD

3:29 PM

@vitidev А оно мне и не нужно, это ж ООП. У меня живой объект, а не DTO.

А прогресс операции приходит через IProgress<T>

vitidev

5:15 PM

@VladD классы с одними методами без публичных свойств что ли

VladD

8:30 PM

@vitidev Я лично избегаю публичных свойств в модельных классах. Разве что иммутабельные. Обмен информацией через разделяемое состояние — зло и не скалируется. Если вам нужно получить результат, просто делайте Task<Результат>. Если вам нужно получить данные о протекании процесса, передавайте Progress<...>.

vitidev

а мне нужно состояние

VladD

@vitidev Я решил эту проблему, сменив дизайн. Многопоточность и состояние не созданы друг для друга. Иммутабельность и локальное состояние (внутри Task'а) для меня лично закрыли вопрос навсегда.

vitidev

иммутабельность имеет цену.

VladD

@vitidev У меня всё работает. Есть кое-где неиммутабельные части, они изолированы от остальной программы правильными интерфейсами.

Ну и «имеет цену» для меня звучит как «преждевременная оптимизация»

Я для себя решаю так: делаю правильно (иммутабельно/таски, в редких случаях IObservable), и если получается медленно, нахожу профилированием пару мест для оптимизации. В которых можно локально отойти от правильной семантики.

vitidev

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

VladD

8:37 PM

@vitidev Я говорю лишь о своём опыте.

А то я видел кучу людей, которые говорили «LINQ не используем, а то проблемы с производительностью гарантированы»

Хуже, некоторые даже от исключений отказывались

В результате получался неработающий код.

Но наверное очень быстрый

У меня внутреннее правило — сначала нужно сделать правильно, а потом ухудшать для производительности.

vitidev

а я отказался от LinkedList в пользу ConcurrentDictionary. список непотокобезопасен и мне не понравились решения. а словарь со своими причудами и GC любит нагружать тоже посильнее списка

VladD

Небольшое исключение: использование правильной структуры данных — обычно не преждевременная оптимизация. Но мутабельное состояние почти всегда превращает многопоточную программу в нечитаемое спагетти, чреватое рейсами и вылетами. Летали, знаем.

Нет разделяемого состояния — нет необходимости синхронизации.

vitidev

а между тем в исходниках того же CancellationTokenSource мы видим volatile

а не барьеры

VladD

@vitidev Да, а в исходниках WPF мы видим ThreeElementArray или что-то такое

vitidev

ага. только вот volatile зло

VladD

8:48 PM

Тип ThreeElementArray — тоже зло

чистое, беспримесное

они там внутри пусть используют что хотят

исходники CLR — не руководство по написанию правильного кода

вот чему бы я поучился — так это правильному составлению публичного API

а так, да, имеют право на говнокод внутри. у них свои констрейнты, у меня свои.

vitidev

а я и не смотрю на них как на руководство. мне интересно как это работает на мультипроцессной системе с ее кешами и тем что volatile не гарантирует волатильность

я не понимаю зачем они прилепили его. и зачем к ссылочным типам

хотя есть и поле int. суть в том что липерт сказал что волатиле юзать безумие ибо он не гарантирует

и я могу не юзать, а дотнет внутри себя юзает и нарушает все

просто хочу разобраться. щас поясню...

липерт говорит что процессор не ждет пока волатиле поле синканется из памяти. просто обеспечиваются более слабые гарантии.

Я понимаю это так - при изменении волатильного поля начинается процесс синхронизации кешей и когда доберется то доберется

в отличие от него барьер заставляет синхронизироваться с основной памятью

так?

VladD

@vitidev Ну у них там конкретный компилятор, который компилирует конкретную конструкцию. И внутри команды сидят зубры, которые точно знают, что вот в данном случае так писать можно, а если соседний иф поменять на вайл, то нельзя. И они имеют право писать код, который сложно поддерживать.

@vitidev Ну и хорошо, пусть нарушает. Милиция иногда нарушает ПДД, чтобы поймать преступника. Но это не повод нам нарушать.

@vitidev Честно? Не знаю.

Тем более, вы о каком volatile говорите?

vitidev

я просто хочу понять подводный камень. я вижу если я применяю барьеры то все равно значение не сможет попасть в другой кеш сразу после изменения - есть некоторое запаздывание туда сюда где в другом кеше будет видно старое значение

и волатиле по факту делает то же самое что 2 барьера

ключевое слово

VladD

Из C++, из C# или из Java? Они все разные.

vitidev

ну вы же исключительно шарпист

VladD

8:58 PM

@vitidev А Эрик о каком говорит?

Не, я не только шарпист. Просто мне не очень нравятся C++ :) А во времена Хэшкода, когда плюсовиков тут не было, отвечал и по нему.

У меня в конце-концов по нему даже медалька какая-то есть

vitidev

о шарпе

VladD

А можно ссылку?

vitidev

blogs.msdn.microsoft.com/ericlippert/2011/06/16/…

In C#, "volatile" means not only "make sure that the compiler and the jitter do not perform any code reordering or register caching optimizations on this variable". It also means "tell the processors to do whatever it is they need to do to ensure that I am reading the latest value, even if that means halting other processors and making them synchronize main memory with their caches".

Actually, that last bit is a lie. The true semantics of volatile reads and writes are considerably more complex than I've outlined here; in fact they do not actually guarantee that every processor stops what i…

если волатиле это 2 барьера то я понимаю что такое "weaker guarantees "

VladD

@vitidev Ну вот я тоже не вполне понимаю, поэтому не лезу туда.

У меня в семантике никогда нет отдельного интового поля, которое нужно читать из разных потоков, вне привязки к другим полям.

vitidev

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

ну а в классе токена отмены вот есть

VladD

9:04 PM

я не вижу для себя смысле экономить на многопоточных операциях.

vitidev

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

VladD

если синхронизацию приходится проводить слишком часто, это ошибка в дизайне

vitidev

нууу сложно писать локи в локфри коде )

VladD

@vitidev уверены? ваша программа, ваши баги

vitidev

уверен. вот у меня коннекты очищаются регулярно. не удалит при первом проходе - не велика беда

VladD

9:05 PM

Повторюсь снова. Я решил для себя проблему на корню отказом от разделяемого между потоками состояния. Смысла отказываться от этого для себя не вижу.

vitidev

ну у вас нет смысла. у меня есть. какая разница у кого какие причины если мы говорим о технических тонкостях

VladD

А структуры с нечистой семантикой («ну тут данные может за этот проход, а может за тот, как получится») вызывают у меня почти физиологическое неприятие.

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

vitidev

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

VladD

Я и к оптимистическим блокировкам отношусь как к ереси

@vitidev Нет, не обязан. Но у меня должны быть строгие гарантии. Потому что гарантия «когда-нибудь отвалится» — это есть отсутствие гарантии

vitidev

я просто ставлю флаг IsConnected=false. при следующей сборке мертвых коннектов его удалит отовсюда. Если этот флаг не доберется одномоментно до всех кешей - это не беда, а вот под лок его кидать - идиотизм

VladD

9:09 PM

@vitidev Вы вот сейчас краеугольный принцип того, как я программирую, назвали идиотизмом вообще-то.

vitidev

нет. я называл КОНКРЕТНЫЙ пример где вызывать лок - оверхед не несущий НИКАКОЙ выгоды. зато очевидный проигрыш

VladD

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

vitidev

@VladD ни когда нибудь, а при следующей сборке мертвых клиентов

VladD

@vitidev А какая гарантия, что значение долетит до другого ядра?

Есть она?

Или «экспериментально»?

vitidev

такая же как у 2х барьеров же

VladD

9:12 PM

@vitidev А можно изъясняться так, чтобы мне было понятно? А то при вот подобных объяснениях я чувствую себя идиотом. Что такое «при двух барьерах»?

Вы пишете загадочную фразу, и как её понять? У меня в голове нет того же контекста, что у вас

@vitidev то есть «у двух барьеров»

Извините за резкость. Но мне и правда сложно доставать из двух слов контекст фразы.

vitidev

ага. я сам запутался. спать пора. волатиле это ж пара VolatileRead и VolatileWrite которые не гарантируют то, что станет видно везде сразу

кстати в шарпе пишут все записи волатильные, потому я не понимаю смысла в VolatileWrite

VladD

@vitidev Вроде ж это не в шарпе, это в CLR на Интеле

То есть в нём VolatileWrite = просто Write

vitidev

есть 2 аспекта
1) перестановка иснтрукций
2) видимость переменной в чужих кешах

1е не нужно, а вот второе интересно. Как я понимаю lock заставит синхронизироваться, а volatile притащитданные с некоторой задержкой

VladD

@vitidev Первое на мой вкус очень важно, и это то, что заставляет меня отказываться от локов. Ну хорошо, допустим, что у вас очень особый случай, и это не важно. Lock ведь тоже компилируется в Monitor.Enter и Monitor.Leave

То есть это тоже два барьера

vitidev

9:29 PM

ну перестановка инструкций это отдельная тема. А у меня задача вида "у меня переключается флаг в одну сторону и когда это увидят другие и оборачивать ли его в lock или можно избежать этого без ущерба"

vitidev

9:42 PM

пошел я спать а то запутался
1) VolatileRead в мсдн говорит что считывает последнее актуальное значение что кто то записал из процессоров независимо от состояния кешей
2) volatile разве не является паролй VolatileRead/VolatileWrite кроме маркера "не оптимизируй"?
3) липер говорит что волатиле зло ибо никто не гарантирует что проц будет ждать (противоерчит пунтку 1).
4) тоуб когда спросили "мол таски это потоки разве не беды с кешами" он ответил "в тпл стоят барьеры в начале и в конце (кажется барьреы), так что беды нет" (потерял цитату нужно найти)

Transcript for

Дискуссии о C#/.NET на русском