Здравствуйте, Sharov, Вы писали:
S>Если везде и всюду использовать типы из ConcurrentCollections, то зуб дам.
А если в эту коллекцию положить изменяемый объект? Ты можешь гарантировать что на этот объект не будет ссылок из разных потоков?
Ты такими темпами без зубов останешься.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Не обязательно язык, и даже необязательно компилятор. Достаточно внешнего верификатора.
В коде всё равно понадобятся аннотации.
Так что получаем язык с компилятором вид с боку.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
EP>>Не обязательно язык, и даже необязательно компилятор. Достаточно внешнего верификатора. WH>В коде всё равно понадобятся аннотации.
Необязательно. Например верификатор может ограничить всё глобальное взаимодействие до одного объекта очереди сообщений.
Да и аннотации уже есть во многих языках, если же нет — то можно для этой цели использовать типы.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Sharov, Вы писали:
S>>Если везде и всюду использовать типы из ConcurrentCollections, то зуб дам. WH>А если в эту коллекцию положить изменяемый объект? Ты можешь гарантировать что на этот объект не будет ссылок из разных потоков? WH>Ты такими темпами без зубов останешься.
Имелись ввиду простейшие операции над коллекциями: добавить, удалить, вставить... Для более-менее приемлемого решения в общем виде надо использовать immutable ds.
Здравствуйте, Sharov, Вы писали:
S>Имелись ввиду простейшие операции над коллекциями: добавить, удалить, вставить... Для более-менее приемлемого решения в общем виде надо использовать immutable ds.
Не обязательно. Есть способы передавать произвольные изменяемые графы между потоками гарантируя что ссылок в старом потоке не останется.
Я уже писал как: Re: Мысли о эффективном автоматическом управлении памятью
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Необязательно. Например верификатор может ограничить всё глобальное взаимодействие до одного объекта очереди сообщений.
Слишком сильное ограничение.
EP>Да и аннотации уже есть во многих языках, если же нет — то можно для этой цели использовать типы.
Так это и получается язык с компилятором, но через зад автогеном.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Не обязательно язык, и даже необязательно компилятор. Достаточно внешнего верификатора.
Это равносиельно языку. Ну, и не факт что достаточно. Для это "верификации" нужна модель. Плюс нужна поддержка в рантайме.
Короче, если бы все был так просто, то проблему эту уже давно решили. Но что-то решения не видно не смотря на монструозные коллективы работающие над этим в Майкрософт, Гугле и Оракле.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Зуб дашь что у тебя в коде нигде нет доступа из разных потоков к данным которые к этому не готовы? WH>Чтобы можно было ответить да для кода из 1000+ строк нужен язык, который это контролирует.
Пока вы это только обсуждаете, в С++ уже есть thread sanitizer а в Go — race detector. Проблема race-ов это конечно проблема, но она стоит не так остро, как некоторые другие проблемы параллельного программирования, которые вы тут с Владом даже не начинали обсуждать. Thread safety это конечно критично, но это простая проблема, которую можно решить на уровне архитектуры. Язык, который не позволит мне написать не thread-safe программу это довольно сомнительно, IMO.
Помимо этого есть еще проблема композиции. В многопоточном программировании, если твоя программа состоит из thread-safe элементов (все коллекции и объекты используют мьютексы например), это не значит что программа является корректной и потокобезопасной.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, Sharov, Вы писали:
S>>Вот lock-free структуры данных эту проблему решают. Голова о синхронизации не болит.
CK>
CK>ты эти lock-free структуры данных сам писать то пробовал?
К чему этот вопрос? Я в курсе про дикую сложность их написания и отладки, особенно для ConcurrentDictionary. Но как это влияет на их полезность и применимость?
Здравствуйте, VladD2, Вы писали:
WH>>В коде всё равно понадобятся аннотации. WH>>Так что получаем язык с компилятором вид с боку. VD>+ еще, наверняка, потребуется рантайм менять.
Зависит от того что делать.
Например, мою систему можно натянуть на любой рантайм с ГЦ.
Повышение производительности, которое можно получить, зная особенности этой системы типов конечно не будет, но гарантии того что объект не будут менять из разных потоков останутся.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, chaotic-kotik, Вы писали:
CK>Пока вы это только обсуждаете, в С++ уже есть thread sanitizer а в Go — race detector.
Зуб дашь что я их не сломаю?
CK>Проблема race-ов это конечно проблема, но она стоит не так остро, как некоторые другие проблемы параллельного программирования, которые вы тут с Владом даже не начинали обсуждать.
Если эта проблема не решена решать остальные не имеет смысла просто по тому что программа не работает.
CK>Thread safety это конечно критично, но это простая проблема, которую можно решить на уровне архитектуры.
Зуб дашь что после очередного изменения ссылка на изменяемый объект не зацепится за два потока?
CK>Помимо этого есть еще проблема композиции. В многопоточном программировании, если твоя программа состоит из thread-safe элементов (все коллекции и объекты используют мьютексы например), это не значит что программа является корректной и потокобезопасной.
Корректность программы понятие неопределённое.
А вот то что программа не меняет объект из двух потоков доказать можно.
Существует несколько систем типов которые это делают.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, chaotic-kotik, Вы писали:
CK>>Пока вы это только обсуждаете, в С++ уже есть thread sanitizer а в Go — race detector. WH>Зуб дашь что я их не сломаю?
Что значит "сломаю"?
WH>Если эта проблема не решена решать остальные не имеет смысла просто по тому что программа не работает.
Т.е. многопоточные программы не работают?
CK>>Thread safety это конечно критично, но это простая проблема, которую можно решить на уровне архитектуры. WH>Зуб дашь что после очередного изменения ссылка на изменяемый объект не зацепится за два потока?
Я это отловлю в тестовом окружении с вероятностью 99.9%.
WH>Корректность программы понятие неопределённое. WH>А вот то что программа не меняет объект из двух потоков доказать можно. WH>Существует несколько систем типов которые это делают.
Это всего навсего одни класс ошибок. Некоторые ошибки многопоточности вообще к падениям не приводят (starvation, false shearing)но тем не менее являются ошибками. Основная сложность это вообще не это, а всякие performance related штуки. Типа, нужен нам счетчик, который бы инкрементировался из разных потоков, можно на атомиках сделать, но это медленно, т.к. contention, а можно сделать счетчик как folly.
Как поможет написать счетчик a-la folly твоя идея я хз.
Здравствуйте, chaotic-kotik, Вы писали:
CK>>>Пока вы это только обсуждаете, в С++ уже есть thread sanitizer а в Go — race detector. WH>>Зуб дашь что я их не сломаю? CK>Что значит "сломаю"?
Сделаю гонку, которую они не поймают.
WH>>Если эта проблема не решена решать остальные не имеет смысла просто по тому что программа не работает. CK>Т.е. многопоточные программы не работают?
Сложные обычно не работают.
Они начинают работать только после очень долгой отладки. И то не факт.
WH>>Зуб дашь что после очередного изменения ссылка на изменяемый объект не зацепится за два потока? CK>Я это отловлю в тестовом окружении с вероятностью 99.9%.
Ещё один адепт секты "тесты гарантируют корректность программы".
CK>Это всего навсего одни класс ошибок.
Но очень гадкий класс ошибок. Примерно, как порча памяти.
Он может приводить к молчаливой порче данных которую никакими тестами не отловить.
Порча данных может быть использована как дыра в безопасности.
CK>Некоторые ошибки многопоточности вообще к падениям не приводят (starvation, false shearing)но тем не менее являются ошибками. Основная сложность это вообще не это, а всякие performance related штуки. Типа, нужен нам счетчик, который бы инкрементировался из разных потоков, можно на атомиках сделать, но это медленно, т.к. contention, а можно сделать счетчик как folly. CK>Как поможет написать счетчик a-la folly твоя идея я хз.
Это примерно, как говорить, что статическая типизация не нужна по тому что она не мешает написать квадратичный алгоритм вместо линейного.
То, о чем ты говоришь это другой класс проблем. И решать его нужно другими методами.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
CK>>Что значит "сломаю"? WH>Сделаю гонку, которую они не поймают.
Good luck with that.
WH>Сложные обычно не работают.
Чойта?
WH>Они начинают работать только после очень долгой отладки. И то не факт.
Все приложения требуют тестирования и любой код может потенциально содержать баги.
WH>Ещё один адепт секты "тесты гарантируют корректность программы".
Добро пожаловать в реальный мир, вот вам вести от сохи: сегодня тесты принято собирать с опцией -fsanitize=thread и -fsanitize=address.
WH>Но очень гадкий класс ошибок. Примерно, как порча памяти.
Если код не трогает одну и ту же память одновременно из разных потоков, это еще не означает, что он потокобезопасен.
WH>Он может приводить к молчаливой порче данных которую никакими тестами не отловить.
-fsanitize=thread
WH>Порча данных может быть использована как дыра в безопасности.
Есть класс дыр в безопасности, т.н. double fetch vulnerabilities вызванных именно race-ами, но ты едва ли сможешь избавиться от них с помощью системы типов. Ну и проявляются они в основном в старых С-style API, где размер буфера передается через указатель (он используется как in/out параметр), поэтому вредоносный код может его заэксплотировать, но это в API вызовах, а обычный RC в приложении как правило нельзя использовать.
WH>Это примерно, как говорить, что статическая типизация не нужна по тому что она не мешает написать квадратичный алгоритм вместо линейного. WH>То, о чем ты говоришь это другой класс проблем. И решать его нужно другими методами.
Я же не говорю что это не нужно, только то, что это не очень полезно, так как thread safety и liveliness не гарантирует.
Здравствуйте, chaotic-kotik, Вы писали:
WH>>Сделаю гонку, которую они не поймают. CK>Good luck with that. https://github.com/google/sanitizers/issues/621
Зубы на полку.
WH>>Сложные обычно не работают. CK>Чойта?
Жизнь такая.
CK>Все приложения требуют тестирования и любой код может потенциально содержать баги.
Только стоимость отладки разных типов багов отличается в разы если не на порядки.
CK>Если код не трогает одну и ту же память одновременно из разных потоков, это еще не означает, что он потокобезопасен.
Рассказывай дальше. Что там такое может произойти?
CK>Есть класс дыр в безопасности, т.н. double fetch vulnerabilities вызванных именно race-ами, но ты едва ли сможешь избавиться от них с помощью системы типов.
Есть несколько разных систем типов которые убивают гонки с 100%ной гарантией.
CK>Я же не говорю что это не нужно, только то, что это не очень полезно, так как thread safety и liveliness не гарантирует.
Ты не крути. Ты расскажи, что может произойти если гонок нет от слова совсем.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
