Программирование[11]

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

но при этом на собесе вот с таким лицом: 

будут спрашивать А ЧТО ТАКОЕ ЛАТЧ?)))))))))))))))))))))))))) пишешь ли ты латчи каждый день от своего рождения??

faceles5 написал 4 часа назад:

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

сложно начать думать в терминах не что будет, а что может быть

в канкаренси проблема в том что невозможно протестировать.

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

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

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

faceles5 написал 3 часа назад:

ну спринг на java синхронщина везде(по умолчанию(даже под капотом)), я с ним работаю

для джавы базу важно знать в любом случае

как бы можно быть спринг-девелопером и жить себе спокойно,

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

я видел очень много примеров когда челы не понимают и обращаются к переменным из разных потоков которые даже volatile не обозначены, не понимают что такое thread safe и тп.

если ты написал объект - ты должен понимать из каких потоков он может быть вызван и что при этом может происходить

Olololnet написал 53 минуты назад:

 А ЧТО ТАКОЕ ЛАТЧ?)

Эт когда в КС соло остался и затащил

Just.Doit написал 45 минут назад:

но компетентный разраб должен хотябы базу понять

Это правда пишет наш немецкий разработчик? 

Grohuf написал 35 минут назад:

Just.Doit написал 1 час назад:

но компетентный разраб должен хотябы базу понять

Это правда пишет наш немецкий разработчик? 

готов спорить что ты в этом обосрешься с подливой

faceles5 написал 20 часов назад:

т.е. с синхронизацией потоков, дедлоки и прочим проблем нету?) или это все с опытом приходит?

 

Пиши код с минимумом точек синхронизации, конкарент-агностик вещами (типо го/корутин или реактивщины), пиши чистые функции и будет тебе счастье.

По факту в энтерпрайзе вся параллельщина заключается в том чтобы форкнуться на N I/O за данными а потом awaitAll чтобы собрать модельку и кинуть на другой слой.

CPU параллелизм я в своей промышленной практике не встречал. 

Index написал 12 минут назад:

faceles5 написал 20 часов назад:

т.е. с синхронизацией потоков, дедлоки и прочим проблем нету?) или это все с опытом приходит?

 

Пиши код с минимумом точек синхронизации, конкарент-агностик вещами (типо го/корутин или реактивщины), пиши чистые функции и будет тебе счастье.

 

По факту в энтерпрайзе вся параллельщина заключается в том чтобы форкнуться на N I/O за данными а потом awaitAll чтобы собрать модельку и кинуть на другой слой.

CPU параллелизм я в своей промышленной практике не встречал. 

 

бтв дико плюсую

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

Just.Doit написал 16 часов назад:

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

Не обязательно полю быть volatile, иногда переменная может быть библиотечная например, что делать будешь? 

Зависит от проекта, конечно, но имхо обычная Spring макака имеет небольшие шансы столкнуться с многопоточкой.

Почему? Потому, что спринг-рест сервера - это стейтлесс история. Тебе общее состояние, зашаренное между несколькими потоками, - не нужно. Состояние во внешнем хранилище лежит(какая то дб). Вот доступ к данным из дб - это да, там уже блокировки на данных возможно понадобятся. Но это решается запросами к базе, а не возней в коде приложения. 

Максимум с чем может столкнуться Spring-макака - это необходимость выполнения некоторых вещей асинхронно. Прикладывай ExecutorService раз в день и болеть не будет.

В большинстве случаев тебе просто надо сходить в базу и вернуть json или принять json и записать в базу.

Spring макака. подписаться

Index написал 1 час назад:

Не обязательно полю быть volatile, иногда переменная может быть библиотечная например, что делать будешь?

напишу тредсейф обертку чтобы были h-b отношения с корректными инвариантами

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

Index написал 1 час назад:

Just.Doit написал 18 часов назад:

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

Не обязательно полю быть volatile, иногда переменная может быть библиотечная например, что делать будешь? 

 

  Скрыть содержимое

 

На самом деле в java есть 4 вида семантик в memory model,а не только  volatile и как бог решит.

И можно оборачивать переменные в необходимый тебе varhandle и работать как с volatile или просто соблюдая семантику попроще и по производительнее volatile

рекомендую годное видео на эту тему

  Скрыть содержимое

 

 

 

 

 

 

ебать

эти ебоклаки еще и за пределы спеки вышли

нахуй вообще спека нужна тогда блять

AmadeusMozzzart написал 1 час назад:

Зависит от проекта, конечно, но имхо обычная Spring макака имеет небольшие шансы столкнуться с многопоточкой.

Почему? Потому, что спринг-рест сервера - это стейтлесс история. Тебе общее состояние, зашаренное между несколькими потоками, - не нужно. Состояние во внешнем хранилище лежит(какая то дб). Вот доступ к данным из дб - это да, там уже блокировки на данных возможно понадобятся. Но это решается запросами к базе, а не возней в коде приложения. 

Максимум с чем может столкнуться Spring-макака - это необходимость выполнения некоторых вещей асинхронно. Прикладывай ExecutorService раз в день и болеть не будет.

В большинстве случаев тебе просто надо сходить в базу и вернуть json или принять json и записать в базу.

 

Spring макака. подписаться

да

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

Just.Doit написал 21 час назад:

в канкаренси проблема в том что невозможно протестировать.

А что мешает? Возможно.

Просто тяжело и дорого покрывать.

Just.Doit написал 3 часа назад:

ебать

эти ебоклаки еще и за пределы спеки вышли

нахуй вообще спека нужна тогда блять

Unsafe это за пределами спеки, а вот https://openjdk.org/jeps/193 как раз спека.

Вообще хорошо что много хитроебства становится частью стандарта, как тот же байткод ЖВМ. 

GoldRobot написал 4 часа назад:

Просто тяжело и дорого покрывать.

ну ты сколько не тестируй это не даст гарантий что завтра на процессоре М123 или версии платформы джава100500 не ебанется по причине того что код не корректный

ну я согласен что в теории ты можешь протестировать 1 миллион разных вариантов окружения (по нагрузке, по компиляторам, по платформе, по цпу, по ос и тп) но это уже не целесообразно просто

Index написал 4 часа назад:

Just.Doit написал 8 часов назад:

ебать

эти ебоклаки еще и за пределы спеки вышли

нахуй вообще спека нужна тогда блять

Unsafe это за пределами спеки, а вот https://openjdk.org/jeps/193 как раз спека.

Вообще хорошо что много хитроебства становится частью стандарта, как тот же байткод ЖВМ. 

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

Index написал 4 часа назад:

Just.Doit написал 8 часов назад:

ебать

эти ебоклаки еще и за пределы спеки вышли

нахуй вообще спека нужна тогда блять

Unsafe это за пределами спеки, а вот https://openjdk.org/jeps/193 как раз спека.

Вообще хорошо что много хитроебства становится частью стандарта, как тот же байткод ЖВМ. 

то что ты скинул не содержит ни слова про эти 2 семантики

Just.Doit написал 3 минуты назад:

ну ты сколько не тестируй это не даст гарантий что завтра на процессоре М123 или версии платформы джава100500 не ебанется по причине того что код не корректный

ну я согласен что в теории ты можешь протестировать 1 миллион разных вариантов окружения (по нагрузке, по компиляторам, по платформе, по цпу, по ос и тп) но это уже не целесообразно просто

Что-то я вообще не понял твоей мысли.

Если ты покрыл тестами, то код корректный должен быть.

GoldRobot написал 11 минут назад:

Если ты покрыл тестами, то код корректный должен быть

ты когданить пробовал покрыть тестами датарейсы или рейскондишн?

ну ты же плюсовик. у вас там UB везде, так?
но ты можешь часто на конкретном компиляторе, на конкретной платформе заюзать UB которое будет работать 100% корректно. но это тем не менее UB

вот тут также

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

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

Just.Doit написал 6 минут назад:

но ты можешь часто на конкретном компиляторе, на конкретной платформе заюзать UB которое будет работать 100% корректно. но это тем не менее UB

я хз как объяснить что канкаренси поведение протестировать невозможно

Тест должен проверять не "работает" или "не работает", а то что поведение ожидаемо, и результат совпадает. Почему мне это объяснять то нужно вообще?

Если ты тестируешь трейд сейфети, то ты и будешь покрывать тестами отсутствие дата рейсов. А не то что оно скомпилилось.

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

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

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

GoldRobot написал 1 час назад:

Твоя идея того что внезапно std::mutex отьебнет на какой-то платформе, или компиляторе, конечно, революционная, я такое даже представить себе не мог.

ты вообще не о том, дурачок

GoldRobot написал 1 час назад:

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

Just.Doit написал 1 час назад:

но ты можешь часто на конкретном компиляторе, на конкретной платформе заюзать UB которое будет работать 100% корректно. но это тем не менее UB

я хз как объяснить что канкаренси поведение протестировать невозможно

Тест должен проверять не "работает" или "не работает", а то что поведение ожидаемо, и результат совпадает. Почему мне это объяснять то нужно вообще?

Если ты тестируешь трейд сейфети, то ты и будешь покрывать тестами отсутствие дата рейсов. А не то что оно скомпилилось.

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

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

 

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

попытаюсь объяснить тупенькому

вот у тебя есть код в мейн треде

var isReady = false

var a = 0

var b = 0

и далее запускаются 2 треда

Тhread1:

var a = 1

var b = 1

var isReady = true

Thread2:

while(!isReady) {

  sleep(1)

}

print(a, b)

Ожидаемое поведение - второй поток напишет (1, 1)

Как это протестировать?

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

другой пример

есть инициализационный код (мейн тред)

var accountA = 100

var accountB = 0

и в два и более потока хуярятся операции перевода с одного аккаунта на другой потипу:

if (accountA>= 100)

accountB+= 100

как ты протестируешь такой код? как напишешь тест?