Just.Doit

нет ты не учитываешь альтернативные издержки (термин специфический, см определние из экономики) навар происходит не там где доходность не отрицательная, а там где наибольшее мат ожидание среди доступных альтернатив условно если у тебя есть акции с мат ожиданием (с учетом инфляции) 5% годовых, а вклады дают 1% годовых то при прочих равных навариваться надо на акциях а не на депозитах и не важно выше депозиты инфляции или нет да просто я не понимаю тогда тезиса про то что там конечное количество состояний которые ты МОЖЕШЬ перебрать, но не делаешь этого для многопотока все тоже самое, просто количество комбинаций больше на "порядок" и ты их точно также можешь перебрать

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

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

кажется это никак не подтверждается экономической теорией если завтра поставят ключевую ставку 50% то инфляция станет только ниже, а депозиты/кредиты будут в районе 45-55% логичнее необорот предположить инфляция должны быть ниже КС, иначе возникает паттерн что выгоднее брать кредит и крутить деньги в экономике чтобы заплатить процент по КС а заработать на инфляции бОльший процент последствия такой политики можно было наблюдать в турции, кста

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

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

а к курсу юаня сколь? а к индийской рупии? а к казахскому тэнге? можно еще к турецкой лире померять С января 2019 года по январь 2024 года инфляция 42% Курс рубль доллар сейчас к курсу ровно 5 лет назад = 89 / 63 = 1.41 А сам доллар как бы тоже обесценивался просто если рубль бы обесценибся на столько же насколько доллар - то курс бы при прочих равных был бы такой же. получается рублять на 41% больше обесценился чем обесценившийся доллар ты это хотел сказать?

С января 2019 года по январь 2024 года инфляция 42% откуд данные? Росстат, как я понимаю. А чего тебя удивляет? величина цифры никогда не суммировал и впервые такую цифру вижу

С января 2019 года по январь 2024 года инфляция 42% откуд данные?

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

причем здесь с++ долбаебушка

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

АХХАХААХХААХ сука аутист вова даже не понял про что речь шла и пошел доказывать что оно не правильное ахахаххаха

ты это прям щас можешь воспроизвести на ноутбуке, лол

ну у тебя тест будет зеленый а код не корректный про что и речь АЗХАХАХАХАХАХ иди нахуй бля вова лучше бы ты не лез ты знаешь что существуют оптимизации и спекулятивные перестановки на этапе компиляции и оптимизации (jit)? все я понял многопоточка это асинхронность локфри код никто не пишет поэтому про него ничего знать не надо и тестировать не надо процессоры гарантируют корректность сами по себе и тот тест протестирует мой код (на самом деле нет) УВ-уровень Вовы

да только код настолько простой что его так много смысла тестировать. имплементация на io гарантирует что все будет так если ты такие комбинаторы используешь. это примерно как тестировать что if работает. если код сложнее и зависимости не тривиальны - это имеет смысл но тебе индекс уже написал что это не многопоток никакой и не канкаренси. это просто асинхронность и последовательность асинхронных выполнений речь шла не про тестирование последовательности асинхронных вызовов а про что-то типа 2 потока пишут результат своей работы в шаред память сторонние потоки снимают результаты с шаред памяти в случайные моменты и должны увидеть консистентную память. прямые локи, мутексы и тп нельзя тк слишком медленно конкретный пример из индексовского видоса можешь взять ссылка с таймкодом с примером: если брать твой кейс и добавить что C зависит на результаты работы A и B, то написать на голых примитивах уже становится не так тривиально как ты такое протестишь - я вот хз условно def C_starts_after_A_and_B_finished(a: () => A, b: () => B, c: (A, B) => None): val atomicInt = AtomicInt aRes bRes def wrap(x: ()=>None) : return () => x() curr = atomicInt.incAndGet() if curr == 2: c(aRes, bRes) executor.run(wrap(() => aRes = a())) executor.run(wrap(() => bRes = b())) Вопрос - корректен ли этот код и почему как ты его протестишь

ну я реализовал сразу более сложный и низкоуровневый вариант то что ты говоришь это вооьбще просто ZIO(a()).zipPar(Zio(b())).flatMap(Zio(c())).run все, 1 строчка я асьюмлю что код не кидает эксепшены тк ошибка передается по значению (типа как в го или в нормальных современных языках) с чем-то вроде паники я не стал заморачиваться. потому что это за скобками многопоточки. в плане многопоточности тот код не может сломаться изза эксепшенов если мы говорим про нарушение последовательности то что с не выполнится - а я ебу что ты подразумевал что с должно выполнится даже в случае ошибки а/б

какого нахуй интерфейса там функционал на уровне функции одной def C_starts_after_A_and_B_finished(a: () => None, b: () => None, c: () => None): val atomicInt = AtomicInt def wrap(x: ()=>None) : return () => x() curr = atomicInt.incAndGet() if curr == 2: c() executor.run(wrap(a)) executor.run(wrap(b)) как это не учевидно из моего описания - я хз

мокаешь клок пишешь тест ПРОТЕСТИРОВАНО кажется это эквивалентно примеру с банковскими аккаунтами который я выше приводил лочишься упорядоченно на 2 инвентаря и делаешь обмен фриз инвентарей через приоритизированный (второй) лок всех инвентарей делаешь тест чтобы проверить что "все корректно" написать анриал как я понял вышестоящих гуру многопоточки - надо напихать слипов между локами и разыне комбинации задержек прогнать. и еще как я понял замокать локи и проверить что они были вызваны - правда мне кажется такие тесты максимально тупы и тестируют то что код который написан действительно выполняется построчно так как он написан.

A и B вызываются сразу параллельно C после завершения A и B Задача понятно или еще нужны уточнения? почти в любом языке (даже самом отсталом) есть из коробки такая функциональность за счет корутин (и прочих континуейшн бейзд асинхронности) и их композиции. так что это 1 строчка и 2 композиционных комбинатора - wait all (a,b) -> run next (c) это даже не задача на многопоточку если ты подразумеваешь собственноручную реализацию на низкоуровневых примитивах синхронизации - вопрос нахуя писать велосипед если есть уже готовые комбинаторы которые гарантировано работают быстро и надежно? но даже если так - это элементарно, ты просто пишешь свою континуацию и реимплементишь по суди эти комбинаторы вручную. запускаешь а и б в параллель, они обернуты в функцию которая помимо их выполнения в конце инкрементит атомик (джавовый, который по сути просто cas) и проверяет его на == 2, если true то запускает c задача не то чтобы на многопоточку, а на континуации/асинхронщину скорее

в скале 1 строчка с библиотекой io, писал такое по кд, весь код был в этом только как я не ебу что ты там подразумеваешь в своем псевдо коде, так и тут не ебу что ты там подразумеваешь в требованиях к этому коды 3 лямбды друг за другом вызвать не сложно в любом языке только кто ебет что ты там под этим подразумеваешь - какие требования по скорости и тп, что ты вообще подразумеваешь под "простенький многопоточный класс" - все в synchronized секции (мутекс) это многопоточный код или нет? я не уверен что ты понимаешь что либо про канкаренси, учитывая какую хуйню ты вбрасываешь как в виде псевдокода так и последующих нелепых пояснения что же ты там имел ввиду вон выше индекс кидывал про семантики канкаренси кода в жвм - мне понятно как это работает, и я даже решал прод задачи на знание этого а тебе? ты понимаешь чем plain отличается от opaque, rel/aq и volatile?

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

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

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

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