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

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

3 лямбды друг за другом вызвать не сложно в любом языке

A и B вызываются сразу параллельно

C после завершения A и B

Задача понятно или еще нужны уточнения?

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

А конкаренси когда тестировать будешь? 

Чтобы шаред стейт и датарейсы были.

Виртуальное время и имитация конкаренси асинхронщиной это конечно заебись, но как мне протестировать что у меня задачи работающие на разных потоках корректно отработают с учетом всех нюансов той же упомянутой Java Memory Model, ThreadLocal и прочей хереборы?

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

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

3 лямбды друг за другом вызвать не сложно в любом языке

 

A и B вызываются сразу параллельно

 

C после завершения A и B

 

Задача понятно или еще нужны уточнения?

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

это даже не задача на многопоточку

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

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

запускаешь а и б в параллель, они обернуты в функцию которая помимо их выполнения в конце инкрементит атомик (джавовый, который по сути просто cas) и проверяет его на == 2, если true то запускает c

задача не то чтобы на многопоточку, а на континуации/асинхронщину скорее

Попытался придумать кейс на понятном языке,

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

Как написать тест который проверит что Алиса и Боб не надюпают вардожей?

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

корректно отработают с учетом всех нюансов той же упомянутой Java Memory Model, ThreadLocal и прочей хереборы?

мокаешь клок

пишешь тест

ПРОТЕСТИРОВАНО

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

Как написать тест который проверит что Алиса и Боб не надюпают вардожей?

кажется это эквивалентно примеру с банковскими аккаунтами который я выше приводил

лочишься упорядоченно на 2 инвентаря и делаешь обмен

фриз инвентарей через приоритизированный (второй) лок всех инвентарей делаешь

тест чтобы проверить что "все корректно" написать анриал

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

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

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

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

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

3 лямбды друг за другом вызвать не сложно в любом языке

 

A и B вызываются сразу параллельно

 

C после завершения A и B

 

Задача понятно или еще нужны уточнения?

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

это даже не задача на многопоточку

 

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

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

запускаешь а и б в параллель, они обернуты в функцию которая помимо их выполнения в конце инкрементит атомик (джавовый, который по сути просто cas) и проверяет его на == 2, если true то запускает c

 

задача не то чтобы на многопоточку, а на континуации/асинхронщину скорее

 

 

Я не говорил что это сложно - наоборот я сказал что это очень просто

Тем не менее я не вижу в твоем посте интерфейса способного принимать лямбда функции

Вы походу все таки гуманитарии - столько текста и воды вместо нескольних строк кода

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

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

А конкаренси когда тестировать будешь? 

Чтобы шаред стейт и датарейсы были.

Виртуальное время и имитация конкаренси асинхронщиной это конечно заебись, но как мне протестировать что у меня задачи работающие на разных потоках корректно отработают с учетом всех нюансов той же упомянутой Java Memory Model, ThreadLocal и прочей хереборы?

 

Тык че напишешь имплементацию которая будет проходить этот тест?

Можешь еще написать имплементацию которая будет проходить тест и иметь баги

Раз мой тест говно - то это должно быть не сложной задачей

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

Тем не менее я не вижу в твоем посте интерфейса способного принимать лямбда функции

какого нахуй интерфейса

там функционал на уровне функции одной

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))

как это не учевидно из моего описания - я хз

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

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

Тем не менее я не вижу в твоем посте интерфейса способного принимать лямбда функции

какого нахуй интерфейса

там функционал на уровне функции одной

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))

 

как это не учевидно из моего описания - я хз

А как же wait all (a,b) -> run next (c)?

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

С эксепшеном в a() или b() c() конечно не стартанет никогда

Ну и мой тест прекрасно пройдет с такой функцией конечно же

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

А как же wait all (a,b) -> run next (c)?

ну я реализовал сразу более сложный и низкоуровневый вариант

то что ты говоришь это вооьбще просто

ZIO(a()).zipPar(Zio(b())).flatMap(Zio(c())).run

все, 1 строчка

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

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

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

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

то что с не выполнится - а я ебу что ты подразумевал что с должно выполнится даже в случае ошибки а/б

Ну тык мой юнит тест идеально работает тоже

Кто пиздел на мой юнит тест?

Кто нить объяснит мне какой баг мой юнит тест не выловит?

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

Ну тык мой юнит тест идеально работает тоже

да

только код настолько простой что его так много смысла тестировать. имплементация на 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()))

Вопрос - корректен ли этот код и почему

как ты его протестишь

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

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

Замокай время и сделай clock.tick до того момента как в топане сменят тему с потокосрача 

 

Потокосрач забавен тем что почти никто из участвующих не пишет многопоточность 99% времени и не пишет топочные тесты - в последнем открыто признаются

 

Зато каждый считает себя неебаца экспертом по теме

 

У меня вот нет уверенности что @Just.Doit или @Grohuf могут реализовать простенький многопоточный класс интерфейс C_starts_after_A_and_B_finished из моего теста

 

Зато обсудить как с точки зрения архитектуры компьютера сделаны memory_barrier - это они в первых рядах

Может я еще Hello World не могу написать? Астрологи объявили неделю тупизны? Один кретин считает, что я не знаю gmock, другой что не умею писать многопоточный код. Вы блять свой уровень показываете, думая, что какое-то знание ваше является особенным.

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

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

Не говори это Голдроботу. Он расстроится.

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

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

Отлично давай тогда теперь у нас execute_in_dag_order(order: (("a", "c"), ("b", "c")), {a: lambda, b: lambda, c: lambda}) где любое число лямбд и любой порядок определенный как DAG

Я это точно также протестирую тем же тестом

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

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

речь шла не про тестирование  последовательности асинхронных вызовов

а про  что-то типа

2 потока пишут результат своей работы в шаред память 

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

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

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

прямые локи, мутексы и тп нельзя тк слишком медленно

 

Раз нельзя локи это lock free code

Lock free code почти никто не пишет включая вас - есть буквально несколько структур которые написаны lock free

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

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

Ебанат ты считал что map быстрее unordered_map

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

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

если брать твой кейс и добавить что 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()))

Вопрос - корректен ли этот код и почему

как ты его протестишь

Протестирую тем же самым тестом без каких либо изменений

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

ссылка с таймкодом с примером:

 

Автор долбаеб

Все операции с int атомарны

Так что такого что он описал случиться не может

Продолжайте хавать это говно от теоретиков

On all modern processors, you can assume that reads and writes of naturally aligned native types are atomic. As long as the memory bus is at least as wide as the type being read or written, the CPU reads and writes these types in a single bus transaction, making it impossible for other threads to see them in a half-completed state. On x86 and x64 there, is no guarantee that reads and writes larger than eight bytes are atomic. This means that 16-byte reads and writes of streaming SIMD extension (SSE) registers, and string operations, might not be atomic.

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

Протестирую тем же самым тестом без каких либо изменений

ну у тебя тест будет зеленый

а код не корректный

про что и речь

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

Так что такого что он описал случиться не может

АЗХАХАХАХАХАХ

иди нахуй

бля вова

лучше бы ты не лез

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

On all modern processors, you can assume that reads and writes of naturally aligned native types are atomic. As long as the memory bus is at least as wide as the type being read or written, the CPU reads and writes these types in a single bus transaction, making it impossible for other threads to see them in a half-completed state. On x86 and x64 there, is no guarantee that reads and writes larger than eight bytes are atomic. This means that 16-byte reads and writes of streaming SIMD extension (SSE) registers, and string operations, might not be atomic.

ты знаешь что существуют оптимизации и спекулятивные перестановки на этапе компиляции и оптимизации (jit)?

все я понял

многопоточка это асинхронность

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

процессоры гарантируют корректность сами по себе

и тот тест протестирует мой код (на самом деле нет)

УВ-уровень Вовы

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

ну у тебя тест будет зеленый

а код не корректный

про что и речь

И что если так будет? У теста нет задачи гарантировать корректный код

Под любой тест можно написать неправильный код банально добавив print()

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

ты знаешь что существуют оптимизации и спекулятивные перестановки на этапе компиляции и оптимизации (jit)?

 

И что что существуют?

Как это относится к моему тезису?

Кто-то когда то наблюдал поведение описанное этим долбаебом в таком коде? Нет?

Может acquire release позволяют перестановки? Странно Вот в плюсах не позволяют

Может в этом коде в принципе возможны какие-то престановки?

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

все я понял

многопоточка это асинхронность

Молодец что понял

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

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

 

Пишешь лок фри код? Покежь

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

процессоры гарантируют корректность сами по себе

 

Интересный вывод я с ним не согласен

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

и тот тест протестирует мой код (на самом деле нет)

 

Тот код что я видел безусловно да

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

УВ-уровень Вовы

Да спасибо

Попробуй начать с уровня "не срать себе в штаны в каждом втором сообщении"

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

вживую кто-нибудь лок фри видел в боевых задачах?

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

вживую кто-нибудь лок фри видел в боевых задачах?

На собеседовании задаю задачку.

А так обычно все ограничивается std::atomic<int>. Но, конечно, как написать спинлок знать полезно. Более сложный код в большинстве случаев просто нет смысла писать. В этом нет смысла, так как в подавляющем большинстве случаев лок делается без смены контекста и обходится недорого. В тех случаях, когда происходит смена контекста, обычно, lock-free кодом не обойтись. Так что сложный lock-free код - это очень редкая специфичная задача.

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

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

вживую кто-нибудь лок фри видел в боевых задачах?

На собеседовании задаю задачку.

А так обычно все ограничивается std::atomic<int>. Но, конечно, как написать спинлок знать полезно. Более сложный код в большинстве случаев просто нет смысла писать. В этом нет смысла, так как в подавляющем большинстве случаев лок делается без смены контекста и обходится недорого. В тех случаях, когда происходит смена контекста, обычно, lock-free кодом не обойтись. Так что сложный lock-free код - это очень редкая специфичная задача.

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

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

Кто-то когда то наблюдал поведение описанное этим долбаебом в таком коде? Нет?

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

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

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

Дело не в блокировке (время выполнения атомарной функции измеряется в наносекундах), а в смене контекста.