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

9:30 AM

@vitidev Доброе утро

Насколько я понимаю, без release-барьера на записывающей стороне и acquire-барьера на читающей вообще никаких гарантий нет

vitidev

@VladD ну относительно доброе. нужно по ночам спать а не дискуссии вести

VladD

более сильные барьеры катят

@vitidev относительно доброе утро :)

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

Volatile.Write или как его там ставит тот же барьер вручную

ну и Volatile.Read

vitidev

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

VladD

@vitidev Не-не, не в шарпе, а на интеловской платформе

не знаю, кто это вам сказал, что в шарпе

blogs.msdn.microsoft.com/oldnewthing/20040914-00/?p=37873

vitidev

igoro.com/archive/volatile-keyword-in-c-memory-model-explained

вот эта спорная статья

However, in C# all writes are volatile (unlike say in Java), regardless of whether you write to a volatile or a non-volatile field. So, the above situation actually never happens in C#.

VladD

9:41 AM

@vitidev Ну это утверждение нужно проверять по спецификации

А я там такого не видел

Зато видел вот это: albahari.com/threading/part4.aspx#_The_volatile_keyword

vitidev

Ознкомимся с методами Thread.VolatileWrite и Thread.VolatileRead более подробно.
В MSDN о VolatileWrite написанно: “Записывает значение непосредственно в поле, так что оно становится видимым для всех процессоров компьютера.”
На самом деле это описание не совсем корректно. Эти методы гарантируют две вещи: отсутствие оптимизаций компилятора1 и отсутствие перестановок инструкций в соответствии с свойставми volatile read или write. Строго говоря метод VolatileWrite не гарантирует, что значение немедленно станет видимым для других процессоров, а метод VolatileRead не гарантирует, что значение не…

VladD

Поскольку статья была написана в лохматом 2010 году, возможно, она говорит только об Майкрософтовской имплементации на интеловской платформе.

@vitidev А это откуда?

vitidev

habrahabr.ru/post/130318

VladD

Ах, хабр :-P

Никогда не считал Хабр источником информации. Прочитайте, например, самый первый комментарий.

vitidev

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

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

VladD

9:48 AM

@vitidev Вы произносите заклинание «когерентность кешей» как будто бы это «право наплевать на многопоточные проблемы». А можно конкретные и точные гарантии, которые она даёт, и на каких конкретно процессорах?

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

Не хочу превращать C# в C++

vitidev

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

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

For each operation, the table shows two things:

Is the entire imaginary thread cache refreshed from main memory before the operation?
Is the entire imaginary thread cache flushed to main memory after the operation?

VladD

@vitidev Которую именно «ту»? Ну и если она противоречит спеке, наши действия?

vitidev

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

VladD

@vitidev Ну так главным источником должны быть не статьи на хабре, а спека

Всё, что противоречит спеке, неверно или не гарантировано.

vitidev

а что есть спека? в мсдн вот
Writes a value to a field immediately, so that the value is visible to all processors in the computer.

VladD

9:57 AM

github.com/dotnet/csharplang/blob/master/spec/README.md

Плюс финальная спека есть в каталоге с Visual Studio

в word'овском документе

vitidev

@VladD вижу там описание языка шарпа, а не работы дотнета

VladD

%MSVCROOT%\VC#\Specifications\1033\CSharp Language Specification.docx

@vitidev А только это и есть норматив.

Как именно C# отображает свои понятия на понятия .NET, его внутреннее дело

Например, локальная переменная имеет право в имплементации превратиться в поле. Но от этого гарантии, существующие для переменной, не пропадают

(Такое происходит, например, в async-функциях)

vitidev

ну так мы никуда не придем
мсдн в своих Thread.VolatileWrite/Thread.VolatileRead говорит о том, что обеспечивает видимость процессорами.
хабр говорит что на самом деле это не совсем так потому что... (там ссылки устарели)
липерт говорит что не гарантирует

что это за реализации такие Thread.VolatileWrite/Thread.VolatileRead что они не гарантируют. почему не гарантируют то. если не гарантируют то зачем они вообще введены

VladD

@vitidev Вот именно поэтому я не пользуюсь разделяемым состоянием, и не имею этих проблем.

В случае, если очень надо, использую lock.

vitidev

10:12 AM

@VladD а что делает lock для решения проблемы синхронизации кешей?

VladD

@vitidev Он гарантирует то, что записанное под одним локом будет прочитано под другим.

vitidev

@VladD а каким образом он это делает? механизм какой?

VladD

И не парит мой мозг с кешами и синхронизацией

@vitidev А вот это мне не интересно. Это забота разработчиков языка

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

vitidev

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

и вот я не могу понять разницы

VladD

@vitidev Заглядывать под юбку имплементации нехорошо. Ну делают они как-то, у меня в голове никогда не возникает мысль «а подсмотрю-ка я, как они делают, и сделаю так же, авось прокатит». Потому что я не знаю, какие именно хитрости у них есть. И в каких случаях можно что делать проще, а в каких нужно сложнее.

То есть можно это зареверсить, если очень постараться. Но зачем?

vitidev

10:23 AM

вы используете локи для 2х вещей
1) что поток будет ждать другой поток если другой захватил блокировку и что то делает
2) что после отпускания блокировки мы зайдя внутрь критической секциии получим актуальное значение

вот только пункт 2 делается как? тот же флюшинг памяти.

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

VladD

@vitidev Вот я не задаюсь такими вопросами.

Они мне гарантируют правильное значение, вот и хорошо.

А какие заклинания в каком случае нужны, ну так это знание пусть останется инкапсулированным в JIT-тере

vitidev

они гарантируют флуш/лоад памяти. именно что гарантируют.
волатиле тоже флюш/лоад памяти, но не гарантируют (липерт)

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

VladD

@vitidev В случае лока я не сомневаюсь, потому что мне дана гарантия.

Мне ваш подход кажется похожим на вот что.

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

vitidev

нууу что про лок что про волатиле в мсдн тоже написано "дана гарантия". в мсдн нет про "нет гарантии". там нет ремарок или оговорок про "нет гарантии".

но именно сомнения заставляют читать слова других "а гарантий то нет".

VladD

@vitidev Ну я уже несколько раз выразил свою точку зрения. C# — высокоуровневый язык, трюки с памятью в нём противоречат духу языка.

vitidev

10:37 AM

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

@VladD ага ага. а unsafe там просто для красоты )))

VladD

Поэтому смысла экономить в стиле «откажусь от лока, получу UB и прирост производительности» для меня кажется кардинально неверным подходом.

vitidev

@VladD а если у вас миллионы локов?

VladD

@vitidev Он для интеропа.

@vitidev Значит, у меня плохой архитектор.

Решать проблемы нужно на высоком уровне.

vitidev

а что тут архитектор. мы сидим на со. ту миллионы одновременных коннектов например. это плохой архитектор виноат что миллионы пользоавтелей могут держать открытые вкладки?

VladD

@vitidev Нет. Но архитектор виноват, что для обработки этого ему нужно по локу на пользователя.

vitidev

10:40 AM

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

VladD

@vitidev Не-не, вот работу архитектора давайте оставим архитектору.

vitidev

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

для каждого вебсокета STA не напасешься.

VladD

> разные части системы шарят этот вебсокет и пишут туда когда им надо.

Вот это с моей точки зрения не выглядит хорошей архитектурой

Это не ООП, это спагетти

Уровень абстракции нулевой

Все пишут всюду. Ну да, нужен миллион локов

В такой архитектуре рейсов не избежать.

Какая правильная — не знаю, тут надо пару месяцев думать сначала.

vitidev

приходит коннект вебсокета. получаем Connection. допустим их миллионы, вот со тому пример. Далее через этот connection c пользователем взаимодействуют много кто. Например сервис heartbeat может слать посылки чтобы не рвало коннект, модуль обновления инфы тоже (те же коментарии). А еще модуль уведомлений "вам сообщение в уголке"

на клиенте браузер разберется по типу сообщения. но на сервере это разные модули которые в итоге сходятся своими сообщениями в одну точку в "пишем в сокет".

а значит нужна очередь на сокете. привет лок. Миллионы локов вызываются частенько. без локов разве что тот …

VladD

@vitidev Не-не, я не могу придумать хорошую архитектуру на коленке.

Пусть этим занимается ваш архитектор.

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

vitidev

10:50 AM

с архитектурой проблем нет. проблема именно в очередности доступа к сокету. сокет нужно защищать иначе туда понапишет. нужна очередь записи. и если очередь защищать локом (а только лок вы и приемлете), то получим миллионы локов. Или STA. но сокетов слишком много даже если их группировать в разные потоки.

компоненты работают с connection/client. а уж он внутри себя организует доступ к сокету. так что все threadsafe, но локи локи

VladD

Если у вас экспоненциальный по сложности алгоритм, оптимизации типа «мемсет вместо цикла» не помогут. Если у вас плохая архитектура, оптимизации типа «volatile вместо lock» не помогут.

> с архитектурой проблем нет

vitidev

илиеще. этот миллион висящий в Task.Delay разве это не миллион таймеров

VladD

Вот в этой точке мы сразу расходимся во мнениях

@vitidev Думаю, что нет, а что? Если и так, тут достаточно одного таймера, понятно.

Это как раз мелкая невредная локальная оптимизация

Но как и со всякой оптимизацией, делать её без профилирования — напрасная трата денег работодателя

Оптимизации в стиле «ну я короче помню, что так когда-то было нужно делать, поэтому и сейчас так делаю» — это не оптимизации. В большинстве случаев это, наоборот, пессимизации.

> сокет нужно защищать иначе туда понапишет

Или нужно придумать архитектуру вместо решета

Если кто угодно имеет право когда угодно писать в сокет, что-то тут не так

Короче, напрягите архитектора, пусть отрабатывает свою зарплату

vitidev

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

VladD

@vitidev Если вместо разумной координации действий различных модулей у вас lock, всё очень плохо.

vitidev

10:58 AM

а кто такие архтитекторы? уж не программисты ли с опытом? интересовались, разбирались и стали архитекторами

или где на архитекторов учат?

VladD

@vitidev Моя не знать.

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

Вот обратное верно: программист без опыта не сможет придумать хорошую архитектуру

vitidev

@VladD хороший архитектор тот кто сделал 100000 плохих архитектур и сделал выводы. и да - он программист с опытом. это не дизайнер

VladD

@vitidev Возможно и так

vitidev

смотрите. то что сокет защищен локом - плохая архитектура, но не "много компонентов работают с клиентом". Потому что внутри клиента можно реорганизовать работу с сокетом в очередь. И кажлый такой клиент не будет слать в свой сокет защищая его личным локом (пусть даже async), а ставить сообщение в очередь (которая без локов) и она уже будет разбирать сообщения автоматически защищая от накладок. итого = 0 lock вообще

сообщения в очередь - это ГЛОБАЛЬНАЯ очередь для всех клиентов, а не личная у клиента. Так лучше

VladD

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

vitidev

11:22 AM

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

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

Transcript for

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