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

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

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

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

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

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

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

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

чел

речь не про то как написать корректный код

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

как ты будешь его тестить?

Ясно, что еще можно было ожидать от псевдо-программиста.

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

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

Ясно, что еще можно было ожидать от псевдо-программиста.

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

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

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

дуит разъебал получается

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

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

Конечно, ведь дуит нарисовал хуйню от пизды. В ней не только потокобезопасность не потестить то, в ней вообще ничего не потестить.

И проверять ты должен не то что "компилятор решит или не решит", а то что ТЫ поставил точку синхронизации. Если ты свой классик пытаешься делать трейд сейф, и хочешь тестировать, то тебе и нужно сделать это проверяемым и тестируемым. Если ты обмазываешь мютексом, то придется и проверить что на момент чтения-записи мютекс поднят. Придется отделить данные, отделить от мютекса. Придется подрочиться с порядком вызовов. Проверить что вызвав метод set(a_value, b_value) ты видишь lock, data.set_implement(a_value, b_value), unlock. В таком и только таком порядке.

В яндекс браузере ну наверняка есть мок который проверяет что при вызове http_get(url) вызывается метод SuvereniousDefense.call_mayor(url, user_home_adress) и потом YandexAdvertizie.embed_advertising(get_response)? Вот и тут так же брат.

Вы пишите же моки в своем яндекс браузере верон? Ведь пишите?

Вы че умственно неполноценные? Под потокобезопасность точно также пишут тесты

https://jasmine.github.io/api/2.6/Clock.html

GoldRobot написал 7 часов назад:

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

ну вот выше конкретной код

покажи как надо

GoldRobot написал 7 часов назад:

В таком и только таком порядке.

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

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

про что и речь собственно

собственно нихуя не понял ты и пошел выебываться

Vova написал 5 часов назад:

Вы че умственно неполноценные? Под потокобезопасность точно также пишут тесты

 

https://jasmine.github.io/api/2.6/Clock.html

ты тож не понял про что толкуем?

давайте на конкретном примере

Есть вот класс Bank

у него есть методы:

def moneyPutByAmt(account, amount): Error | OK

def transfer(fromAccount, toAccount, amount): Error | OK

def getAccountBalance(account): Int

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

как написать тест чтобы проверить их потокобезопасность?

Датарейсы невозможно протестировать, потому что потоки в непредсказуемом контексте будут взаимодействовать

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

Сработает не под каждую архитектуру и машину, потому что машинная инструкция может не быть атомарной для исполнения

Vova написал 5 часов назад:

Вы че умственно неполноценные? Под потокобезопасность точно также пишут тесты

 

https://jasmine.github.io/api/2.6/Clock.html

я писал код с подобными моками

он позволяет засетапить некоторые инварианты и проверить их более менее достоверно

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

UglyBastard написал Только что:

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

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

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

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

Так так так

Ты намекаешь что с тестами однопоточных программ как-то по другому?

Vova написал 57 минут назад:

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

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

 

Так так так

 

Ты намекаешь что с тестами однопоточных программ как-то по другому?

 

на высоком уровне абстракции - нет

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

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

Есть вот класс Bank

у него есть методы:

def moneyPutByAmt(account, amount): Error | OK

def transfer(fromAccount, toAccount, amount): Error | OK

def getAccountBalance(account): Int

 

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

 

как написать тест чтобы проверить их потокобезопасность?

Ну, у тебя же очевидно Bank не в воздухе лежит, а является приватным полем ThreadSafeBank класса, который перекрывает эти 3 метода.

Вот и проверь, что перед любой операцией с Bank, поднимается лок. А потом опускается.

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

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

Можешь, но не можешь. Очень странно жанглируешь словами.

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

Тоесть, все так же как и абсолютно с другим кодом сложнее чем 'decode(str)->json', когда тебе нужно протестировать результат не отдаваемый собственно тебе напрямую.

Спасибо что согласился переписав на свой лад.

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

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

является приватным полем ThreadSafeBank класса

это и является ThreadSafeBank класс

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

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

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

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

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

ты опять не понял(

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

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

ну ты вообще предлагаешь детали имплементации тестировать как дефолт подход

что как бы говорит о твоем уровне

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

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

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

Не позорься. Хватит уже.

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

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

ну ты вообще предлагаешь детали имплементации тестировать как дефолт подход

Чел, ты, ты... 

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

По факту есть что сказать? Дуит попытался, разьебался. Ты следующий.

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

По факту есть что сказать? Дуит попытался, разьебался. Ты следующий.

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

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

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

А эт, подвешивание потока условным слипом не даст более-менее приемлемый результат? Проблема в разницы поведении самого условного слипа на разных платформах?

Не пиздите ток, я макака.

Arzanis написал 9 минут назад:

А эт, подвешивание потока условным слипом не даст более-менее приемлемый результат? Проблема в разницы поведении самого условного слипа на разных платформах?

Не пиздите ток, я макака.

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