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

R>Отпадает необходимость навешивать атрибут на параметр, что немного уменьшает визуальный шум, да и контракт читается как код, что на мой взгляд проще, чем выискивать глазами навешанные атрибуты

Если можно, продолжаем тут

Автор: samius
Дата: 28.03.16

.

А я вспомнил, почему я так не делал.
Вот из-за этого поведения.

Можешь сам попробовать. Без [NotNull] на атрибуте вот такой ассерт

            string a = new Random().Next() != 0 ? null : "";
            Code.NotNull(a, nameof(a));
            Console.WriteLine(a);

предупреждений не выдаёт.

* В NotNull почему-то проверяемый параметр как [CanBeNull] помечен. Эт баг, исправлю.

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

VD>Реально насущной проблемой, на мой взгляд, является проблема многопоточной разработки. В современных языках только полная неизменяемость позволяет уберечь код из одного потока от изменений в другом. Вот в этом направлении нужно придумывать новые концепции.

На самом деле многопоточная разработка сейчас и так сильно упростилась благодаря таскам и RX. У меня в десктопной программе целая куча рабочих потоков, но ни одного низкоуровнего примитива синхронизации. Проблем связанных с многопоточностью за 3 года разработки и активного использования было ровно 0. Единственное что было, это попытка прибиндить значение из не-UI потока (WPF), но и для этого в конце концов я сделал припарку, которая автоматом всё перенаправляет.

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

I>На самом деле многопоточная разработка сейчас и так сильно упростилась благодаря таскам и RX. У меня в десктопной программе целая куча рабочих потоков, но ни одного низкоуровнего примитива синхронизации. Проблем связанных с многопоточностью за 3 года разработки и активного использования было ровно 0.

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

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

Как говорил робот Бэндер из Футурамы — "Не стоит поручать человеку работу машины".

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

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

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

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

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

I>>На самом деле многопоточная разработка сейчас и так сильно упростилась благодаря таскам и RX. У меня в десктопной программе целая куча рабочих потоков, но ни одного низкоуровнего примитива синхронизации. Проблем связанных с многопоточностью за 3 года разработки и активного использования было ровно 0.

VD>Это все живет на честном слове и потому что над твоим проектом работаешь ты один.
Спасибо, конечно, за такое доверие к моим скиллам в многопоточности, но живёт оно далеко не на честном слове.

VD>А если у тебя код пишет человек 20, да еще и терриоториально удаленных друг от друга людей с разной квалификацией, то проблемы гарантированы.
Это называется "поддерживаемость" и у тасков/rx она объективно значительно выше, чем у ручного управления потоками.

VD>Прибавь сюда еще требования производительности и получишь еще более печальную картину.
Найти задачу, в которой ты упрёшься в ограничения производительности тасков или даже Rx очень непросто. Они реально очень быстры, несмотря на свою высокоуровневость.

VD>Как говорил робот Бэндер из Футурамы — "Не стоит поручать человеку работу машины".
VD>Язык и рантайм должны брать на себя гарантии безопасности в многопоточных приложения и обеспечение максимально возможной производительности.
VD>По сему нужна контролируемая изменяемость, внятная концепция владения объектами, специализированные кучи и т.п. И все это должно быть не в экспериментальных разработках, а в рантайме вроде дотента или явы.
Возможно. Но, повторюсь, проблем с многопоточностью у тех, кто умеет пользоваться нужными инструментами практически не возникает. Если же ты дерижируешь данными внучную, то без помощи рантайма и правда не обойтись.

VD>Ни RX, ни передача сообщений мне никак не поможет, если у меня имеются данные.
Очень странное утверждение. Вроде как оно именно для этого и создавалось. Надо просто немного поменять мышление.

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

I>Это называется "поддерживаемость" и у тасков/rx она объективно значительно выше, чем у ручного управления потоками.

Это называется наличие гарантий. То что она у RX выше чем у еще более низкоуровневого подхода не означает, что этого достаточно. Можно было бы добиться куда большего.

VD>>Прибавь сюда еще требования производительности и получишь еще более печальную картину.
I>Найти задачу, в которой ты упрёшься в ограничения производительности тасков или даже Rx очень непросто. Они реально очень быстры, несмотря на свою высокоуровневость.

Ну, вот как бы я другие решаю редко. У меня в качестве данных живет выхлоп прасера/типизатора. Я просто не могу сделать весе данные на 100% неизменяемыми или серилизуемыми. Если я сериализую выхлоп парсера, получатся десятки или даже сотни мегабайт, так что эффективность будет на нуле.

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

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

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

Вот это ваше "умеет" очень смахивает на позицию С++-ников — "А я все грабли уже изучил и наступаю на них очень редко". Контроль проекта потернами и усилием воли — это привнесение дополнительной сложности. Если эту работу поручить "машине", можно разгрузить себя и сделать код куда более высокоуровневым. Этот твой RX — это тоже усложнение кода. Да и пригоден он только в некоторых рамках.

VD>>Ни RX, ни передача сообщений мне никак не поможет, если у меня имеются данные.
I>Очень странное утверждение.

Там опечатка. Имелось в виду "если у меня изменяются данные".

I>Вроде как оно именно для этого и создавалось. Надо просто немного поменять мышление.

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

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

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

S>Ну так там цель не сделать ещё один эрланг, а прикрутить scalable multitasking к мейнстриму.
S>http://thenewstack.io/project-orleans-different-than-erlang-designed-for-a-broad-group-of-developers/
S>И оно таки работает.

Об Orleans я только от тебя услышал. Спасибо за ссылку, но что-то там очень много букв из которых совершенно не ясны детали.

Можно в двух словах поведать что мне даст этот Orleans в области контроля изменения данных из разных потоков и (если даст) то чем определяются эти гарантии?

VD>>Тут надо капитально менять язык и парадигму.
S>Судьба любого языка с "нам пофиг на совместимость, зато всё идеально" — не выбираться из дев-лаборатории.

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

Во-вторых, сам C# не имел никакой совместимости ни с чем, но почему-то успешно выжил. Большая компания сумела навязать новый язык и новую платформу рынку.

S>Поэтому или работаем с тем, что есть в мейнстриме, или никак.

Это не более чем оправдание для того чтобы ничего не делать.

S>Насколько вся затея с "правильной" многопоточностью важна для разработчиков сама по себе узнать несложно. Смотрим на популярность эрлангоскалы.

Популярность определяется отнюдь не возможностями и удобством.

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

Распределение вычислений по сети тоже весьма не просто для этого самого мэйнстрима. В то же время Эрланг позволяет это делать уже очень давно и довольно удобно/эффективно.

S>Такой вопрос — ты материалы по Orleans изучал? Если нет — то что мы обсуждаем?

Об Orleans я услышал только от тебя, но что-то то что ты мне дал это какая-то вода. Хотелось бы понять задачи Orleans. Как я понял это что-то на основе посылки сообщений, но детали не ясны. Что там такого, что я не могу сделать сам? И как Orleans позволяет мне избежать имеющихся проблем?

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

Мне хотелось бы видеть:
1. Контролируемую изменяемость данных. Например, чтобы была гарантия, что данные меняется только в одном потоке, а другие читают эти данные во время когда они не изменяются.
2. Нечто позволяющее управлять владением данных, так чтобы можно было передавать изменяемые структуры между потоками не боясь, что они будут изменены не синхронно.
3. Наличие чего то вроде изолированных псевдо-процессов, которые могут быть как реальными процессами (одной или на разных машинах), так и программно изолированными. При этом должны даваться гарантии безопасности данных в этих процессах (что данные не меняются не синхронно).

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

VD>>Все эти Асинки — это как мертвому припарка. От ошибок связанных с изменением состояния в многопоточном мире это не спасает.
S>Ну вот в наших проектах их практически 0.

Слово "практически" мня всегда радовал, в подобных разговорах. У С++-ников практически не бывает порчи памяти, у питонистов практически не бывает ошибок связанных с типами, в ваших проектах практически не бывает ошибок...

Это все самообман. Вы тратите не мало ресурсов на самокороль. И это снижает ваши возможности.

S>Особенно если сравнивать с тем, что было до тасков.

Если сравнивать С++ с ассемблером, там тоже не хилый прогресс в безопасности кода наблюдается. А вот если сравнивать с потенциально гарантированно безопасным решением, то проблемы есть. И чем сложнее софт, тем больше эти проблемы тормозят его разработку.

S>Просто потому, что можно расписать код в CPS или в reactive-style и не возиться с примитивами. Т.е. нужда в разделяемом состоянии отпадает, вместе с ним — и сами баги

Я это 100 раз слышал. В С++ можно обложиться умными указателями и изучить все паттерны правильного программирования, в Питоне можно обложиться тестами и писать мелкие, слабосвязанные островки кода (веб-странички, например). А вот в дотнете можно использовать таски и RX обложившись запретами на изменяемое состояние и т.п.

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

То что МС копает в нужных направлениях — это хорошо. Но как-то уж это очень долго и безрезультатно.

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

VD>Мне хотелось бы видеть:
VD>1. Контролируемую изменяемость данных. Например, чтобы была гарантия, что данные меняется только в одном потоке, а другие читают эти данные во время когда они не изменяются.
VD>2. Нечто позволяющее управлять владением данных, так чтобы можно было передавать изменяемые структуры между потоками не боясь, что они будут изменены не синхронно.
VD>3. Наличие чего то вроде изолированных псевдо-процессов, которые могут быть как реальными процессами (одной или на разных машинах), так и программно изолированными. При этом должны даваться гарантии безопасности данных в этих процессах (что данные не меняются не синхронно).

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

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

WH>Я тебе уже рассказывал, как это сделать. Но ты даже не попытался понять. Хотя сам поднял тему...

Не надо считать себя умнее других.

Меня рассказы не интересуют. Я тебе сам могу много чего рассказать. Меня интересует доступная и удобная реализация.

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

VD>Можно в двух словах поведать что мне даст этот Orleans в области контроля изменения данных из разных потоков и (если даст) то чем определяются эти гарантии?
Рой акторов в облаке. Low latency, отказоустойчивый, без заморочек с синхронизацией и по сложности написания / использования кода не сложнее обычных вызовов через await.
Все акторы изолированы друг от друга, разделяемого состояния нет.
Подробнее вот тут и по ссылкам в том же разделе.


VD>Тут надо капитально менять язык и парадигму
VD>Во-первых, на совместимость можно и не плевать. В язык можно ввести средства позволяющие получить нужный контроль не отказываясь от имеющихся средств.
Взаимоисключающие вещи же.


VD>Уже даже мобильное железо имеет существенное число процессоров. Это создает нишу для языков (или чего-то еще) позволяющих получать существенный прирост производительности на многопроцессорном железе. Сейчас написание такого софта крайне сложно и не приводит к существенному ускорению вычислений за счет распараллеливания.
Для выигрыша от распараллеливания расчётов нужны алгоритмы и знание матчасти. Ну, т.е. тут помогут библиотеки, а не язык. Для сложного диспатча — снова библиотеки, т.к. ни один диалект не покроет весь API тех же тасков, скажем.
Не, от языка толк конечно будет, но в первую очередь — как от инструмента для разработки таких библиотек.

VD>Мне хотелось бы видеть:
Ну вот примерно это и midori и orleans и предоставляют. Для midori см раздел execution model и дальше вот тут, доки на Orleans — ссылка выше.


VD>Слово "практически" мня всегда радовал, в подобных разговорах. У С++-ников практичеси не бывает порчи памяти, у питонистов практически не бывает ошибок связанных с типами, в ваших проектах практически не бывает ошибок...
Не, "практически@ тут значит, что я не припомню ни одной за три года. Может, что-то и было, но лично я не встречал. До этого, с колхозом на потоках / блокировках / interlocked, земли наелись с запасом


VD>Это все самообман. Вы тратите не мало ресурсов на самокороль. И это снижает ваши возможности.
Вот чем мне нравится rsdn — тут всегда готовы рассказать, что у меня происходит на самом деле
Весь самоконтроль заключается в использовании Task.Run()/await/Task.WnenAll() и не использовании разделяемого изменяемого состояния.

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

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

VD>Меня рассказы не интересуют. Я тебе сам могу много чего рассказать. Меня интересует доступная и удобная реализация.
У нитры тоже пока нет реализации но это мешает тебе её писать.
Ибо есть чёткое обоснование того что это правильный путь.

Так и тут. Есть конкретная математика, которая позволяет передавать любые изменяемые графы объектов между потоками без копирования. При этом имея статические гарантии отсутствия гонок.
Более того эту систему типов можно совместить с менеджером памяти что позволит удалять большинство объектов без вызова сборщика мусора.

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

WH>Так и тут. Есть конкретная математика, которая позволяет передавать любые изменяемые графы объектов между потоками без копирования. При этом имея статические гарантии отсутствия гонок.
WH>Более того эту систему типов можно совместить с менеджером памяти что позволит удалять большинство объектов без вызова сборщика мусора.

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

От МС я хочу чтобы они просто взяли и реализовали то что нужно миллионам программистов во всем мире. У них для этого ресурсов достаточно. Но они все копают в других направления и затягивают процесс на десятки лет.

Вот у тебя ведь есть идеи как сделать инкрементальное редактирование и параметризированных правил (чтобы можно было, в частности, отступные грамматики парсить)? Обстоятельства? Так почему уже год у нас нет ни того не другого? Вот у МС (точнее отдельных ее групп и менеджеров) тоже есть какие-то обстоятельства. Результат — прогресс буксует многие годы.

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

S>Рой акторов в облаке. Low latency, отказоустойчивый, без заморочек с синхронизацией и по сложности написания / использования кода не сложнее обычных вызовов через await.
S>Все акторы изолированы друг от друга, разделяемого состояния нет.
S>Подробнее вот тут и по ссылкам в том же разделе.

Это все здорово, но как какая-то не ведомая штука в облаках поможет мне использовать второй процессор на моей машине?

VD>>Тут надо капитально менять язык и парадигму
VD>>Во-первых, на совместимость можно и не плевать. В язык можно ввести средства позволяющие получить нужный контроль не отказываясь от имеющихся средств.
S>Взаимоисключающие вещи же.

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

S>Для выигрыша от распараллеливания расчётов нужны алгоритмы и знание матчасти. Ну, т.е. тут помогут библиотеки, а не язык. Для сложного диспатча — снова библиотеки, т.к. ни один диалект не покроет весь API тех же тасков, скажем.

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

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

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

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

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

VD>>Это все самообман. Вы тратите не мало ресурсов на самокороль. И это снижает ваши возможности.
S>Вот чем мне нравится rsdn — тут всегда готовы рассказать, что у меня происходит на самом деле

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

S>Весь самоконтроль заключается в использовании Task.Run()/await/Task.WnenAll() и не использовании разделяемого изменяемого состояния.

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

S>Не, понятно, что для сложной и большой системы этот колхоз не тянет и нужен нормальный фреймворк / другой язык, но мы-то не об исключениях, а об общей картине говорим

Именно! В простых примерах все всегда очевидно и баги сделать сложно. А вот когда у тебя передаваемых объект — это монстр описывающих сложные вещи, то самоконтроль начинает сдавать.

Имея же железный программный или аппаратный контроль мы можем писать распараллеливать код с той же сложностью (с теми же затрачиваемыми усилиями), с какой сейчас мы пишем простой однопоточный код. Его написание (точнее чтение), кстати, тоже надо как-то упрощать. Но это уже отдельный разговор.