#multithreading — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #multithreading, aggregated by home.social.
-
This was a really nice episode by #computerphile. Earlier I knew only about race conditions. Now I know what sequential consistency and how to reason about race conditions.
-
This was a really nice episode by #computerphile. Earlier I knew only about race conditions. Now I know what sequential consistency and how to reason about race conditions.
-
This was a really nice episode by #computerphile. Earlier I knew only about race conditions. Now I know what sequential consistency and how to reason about race conditions.
-
This was a really nice episode by #computerphile. Earlier I knew only about race conditions. Now I know what sequential consistency and how to reason about race conditions.
-
This was a really nice episode by #computerphile. Earlier I knew only about race conditions. Now I know what sequential consistency and how to reason about race conditions.
-
Локальное нагрузочное тестирование в Java с использованием Virtual Threads
Всем привет! Меня зовут Михаил, я работаю главным экспертом в ОТП Банке. Я люблю тестировать свои решения и почти всегда пишу unit- и integration-тесты. Но вот с нагрузочным тестированием ситуация обычно совсем другая: о нем вспоминают ближе к релизу, когда архитектуру уже поздно менять. В какой-то момент я поймал себя на мысли: А как вообще заранее понять, сколько ресурсов будет потреблять сервис под нагрузкой? Сколько памяти съест приложение? Когда упрется в CPU? Как поведет себя БД при разном кол-ве запросов? Чтобы ответить на эти вопросы, я написал небольшую библиотеку для локального нагрузочного тестирования на Java Virtual Threads. Она запускает большое количество задач, собирает метрики и формирует отчет - прямо в консоли или в CSV. Сегодня я покажу сам подход, разберу код библиотеки и оставлю ссылку на GitHub-репозиторий, чтобы вы могли попробовать ее у себя или адаптировать под свои задачи.
https://habr.com/ru/articles/1035238/
#java #virtual_threads #multithreading #виртуальные_потоки #нагрузочное_тестирование #нагрузочное_тестрование #unittesting
-
Локальное нагрузочное тестирование в Java с использованием Virtual Threads
Всем привет! Меня зовут Михаил, я работаю главным экспертом в ОТП Банке. Я люблю тестировать свои решения и почти всегда пишу unit- и integration-тесты. Но вот с нагрузочным тестированием ситуация обычно совсем другая: о нем вспоминают ближе к релизу, когда архитектуру уже поздно менять. В какой-то момент я поймал себя на мысли: А как вообще заранее понять, сколько ресурсов будет потреблять сервис под нагрузкой? Сколько памяти съест приложение? Когда упрется в CPU? Как поведет себя БД при разном кол-ве запросов? Чтобы ответить на эти вопросы, я написал небольшую библиотеку для локального нагрузочного тестирования на Java Virtual Threads. Она запускает большое количество задач, собирает метрики и формирует отчет - прямо в консоли или в CSV. Сегодня я покажу сам подход, разберу код библиотеки и оставлю ссылку на GitHub-репозиторий, чтобы вы могли попробовать ее у себя или адаптировать под свои задачи.
https://habr.com/ru/articles/1035238/
#java #virtual_threads #multithreading #виртуальные_потоки #нагрузочное_тестирование #нагрузочное_тестрование #unittesting
-
Локальное нагрузочное тестирование в Java с использованием Virtual Threads
Всем привет! Меня зовут Михаил, я работаю главным экспертом в ОТП Банке. Я люблю тестировать свои решения и почти всегда пишу unit- и integration-тесты. Но вот с нагрузочным тестированием ситуация обычно совсем другая: о нем вспоминают ближе к релизу, когда архитектуру уже поздно менять. В какой-то момент я поймал себя на мысли: А как вообще заранее понять, сколько ресурсов будет потреблять сервис под нагрузкой? Сколько памяти съест приложение? Когда упрется в CPU? Как поведет себя БД при разном кол-ве запросов? Чтобы ответить на эти вопросы, я написал небольшую библиотеку для локального нагрузочного тестирования на Java Virtual Threads. Она запускает большое количество задач, собирает метрики и формирует отчет - прямо в консоли или в CSV. Сегодня я покажу сам подход, разберу код библиотеки и оставлю ссылку на GitHub-репозиторий, чтобы вы могли попробовать ее у себя или адаптировать под свои задачи.
https://habr.com/ru/articles/1035238/
#java #virtual_threads #multithreading #виртуальные_потоки #нагрузочное_тестирование #нагрузочное_тестрование #unittesting
-
Локальное нагрузочное тестирование в Java с использованием Virtual Threads
Всем привет! Меня зовут Михаил, я работаю главным экспертом в ОТП Банке. Я люблю тестировать свои решения и почти всегда пишу unit- и integration-тесты. Но вот с нагрузочным тестированием ситуация обычно совсем другая: о нем вспоминают ближе к релизу, когда архитектуру уже поздно менять. В какой-то момент я поймал себя на мысли: А как вообще заранее понять, сколько ресурсов будет потреблять сервис под нагрузкой? Сколько памяти съест приложение? Когда упрется в CPU? Как поведет себя БД при разном кол-ве запросов? Чтобы ответить на эти вопросы, я написал небольшую библиотеку для локального нагрузочного тестирования на Java Virtual Threads. Она запускает большое количество задач, собирает метрики и формирует отчет - прямо в консоли или в CSV. Сегодня я покажу сам подход, разберу код библиотеки и оставлю ссылку на GitHub-репозиторий, чтобы вы могли попробовать ее у себя или адаптировать под свои задачи.
https://habr.com/ru/articles/1035238/
#java #virtual_threads #multithreading #виртуальные_потоки #нагрузочное_тестирование #нагрузочное_тестрование #unittesting
-
Меня раздражает, как объясняют асинхронность
Если что такое параллелизм более-менее все разработчики понимают, то объяснение асинхронности через аналогии с кассирами/поварами вредно, так как вводит в очень большое заблуждение. В данной статье я разберу эту проблему на примерах Python и Go и попробую дать свою правильную аналогию.
-
Меня раздражает, как объясняют асинхронность
Если что такое параллелизм более-менее все разработчики понимают, то объяснение асинхронности через аналогии с кассирами/поварами вредно, так как вводит в очень большое заблуждение. В данной статье я разберу эту проблему на примерах Python и Go и попробую дать свою правильную аналогию.
-
Меня раздражает, как объясняют асинхронность
Если что такое параллелизм более-менее все разработчики понимают, то объяснение асинхронности через аналогии с кассирами/поварами вредно, так как вводит в очень большое заблуждение. В данной статье я разберу эту проблему на примерах Python и Go и попробую дать свою правильную аналогию.
-
Меня раздражает, как объясняют асинхронность
Если что такое параллелизм более-менее все разработчики понимают, то объяснение асинхронности через аналогии с кассирами/поварами вредно, так как вводит в очень большое заблуждение. В данной статье я разберу эту проблему на примерах Python и Go и попробую дать свою правильную аналогию.
-
Деконструкция GO: CPU, RAM и что там происходит. Многозадачность, многопоточность, кэши, проблемы. Часть 1.2
В прошлой статье я немного слукавил, сказав, что мы будем разбирать атомики, барьеры и системные вызовы. Я пару дней поразмышлял и осознал – а зачем вообще это объяснять, если мы даже не знаем про причину их возникновения и проблемы, которые они решают В части 1.1 мы рассмотрели базовые инструкции, которые выполняет наш CPU и которыми в конечном счете и являются наши прекрасные строчки на Go. Но возникает закономерный вопрос: “Окей, мы поняли как работает на одном ядре, но Go у нас во многом про многопоточку, соответственно как это будет работать на нескольких потоках?” Если что, то это часть большого цикла по разбору Go! Данная статья – это подводка уже к тому, с чем мы имеем дело в Go достаточно часто(барьеры памяти, атомики, сисколы) В этот раз будет без Go Assembler, но с +- реальными примерами, если что-то непонятно будет, то на Хабре есть классный ИИ-помощник Многозадачность Хоть мы и развенчиваем в этом цикле абстракции, придется немного к ним вернуться. Но ненадолго! Вспоминаем, как у нас выполняются инструкции в процессоре и представляем следующую конфигурацию: Есть какое-то количество ГБ RAM Есть 1 ядро CPU Соответственно в один момент CPU может выполнять ровно 1 набор инструкций Но почему-то всё во времена одноядерных CPU работало непрерывно… На самом деле нет! Работало еще как с прерываниями(не путать с теми, которые interrupt), просто настолько быстро, что мы были неспособны это осознать, а для того, чтобы успевали работать фоновые службы, приложения и что бы то ни было ещё как раз и придумали многозадачность !
https://habr.com/ru/articles/1024868/
#assembler #go #multithreading #multitasking #race_condition #cache_contention #cpu #ram #linux
-
Деконструкция GO: CPU, RAM и что там происходит. Многозадачность, многопоточность, кэши, проблемы. Часть 1.2
В прошлой статье я немного слукавил, сказав, что мы будем разбирать атомики, барьеры и системные вызовы. Я пару дней поразмышлял и осознал – а зачем вообще это объяснять, если мы даже не знаем про причину их возникновения и проблемы, которые они решают В части 1.1 мы рассмотрели базовые инструкции, которые выполняет наш CPU и которыми в конечном счете и являются наши прекрасные строчки на Go. Но возникает закономерный вопрос: “Окей, мы поняли как работает на одном ядре, но Go у нас во многом про многопоточку, соответственно как это будет работать на нескольких потоках?” Если что, то это часть большого цикла по разбору Go! Данная статья – это подводка уже к тому, с чем мы имеем дело в Go достаточно часто(барьеры памяти, атомики, сисколы) В этот раз будет без Go Assembler, но с +- реальными примерами, если что-то непонятно будет, то на Хабре есть классный ИИ-помощник Многозадачность Хоть мы и развенчиваем в этом цикле абстракции, придется немного к ним вернуться. Но ненадолго! Вспоминаем, как у нас выполняются инструкции в процессоре и представляем следующую конфигурацию: Есть какое-то количество ГБ RAM Есть 1 ядро CPU Соответственно в один момент CPU может выполнять ровно 1 набор инструкций Но почему-то всё во времена одноядерных CPU работало непрерывно… На самом деле нет! Работало еще как с прерываниями(не путать с теми, которые interrupt), просто настолько быстро, что мы были неспособны это осознать, а для того, чтобы успевали работать фоновые службы, приложения и что бы то ни было ещё как раз и придумали многозадачность !
https://habr.com/ru/articles/1024868/
#assembler #go #multithreading #multitasking #race_condition #cache_contention #cpu #ram #linux
-
Деконструкция GO: CPU, RAM и что там происходит. Многозадачность, многопоточность, кэши, проблемы. Часть 1.2
В прошлой статье я немного слукавил, сказав, что мы будем разбирать атомики, барьеры и системные вызовы. Я пару дней поразмышлял и осознал – а зачем вообще это объяснять, если мы даже не знаем про причину их возникновения и проблемы, которые они решают В части 1.1 мы рассмотрели базовые инструкции, которые выполняет наш CPU и которыми в конечном счете и являются наши прекрасные строчки на Go. Но возникает закономерный вопрос: “Окей, мы поняли как работает на одном ядре, но Go у нас во многом про многопоточку, соответственно как это будет работать на нескольких потоках?” Если что, то это часть большого цикла по разбору Go! Данная статья – это подводка уже к тому, с чем мы имеем дело в Go достаточно часто(барьеры памяти, атомики, сисколы) В этот раз будет без Go Assembler, но с +- реальными примерами, если что-то непонятно будет, то на Хабре есть классный ИИ-помощник Многозадачность Хоть мы и развенчиваем в этом цикле абстракции, придется немного к ним вернуться. Но ненадолго! Вспоминаем, как у нас выполняются инструкции в процессоре и представляем следующую конфигурацию: Есть какое-то количество ГБ RAM Есть 1 ядро CPU Соответственно в один момент CPU может выполнять ровно 1 набор инструкций Но почему-то всё во времена одноядерных CPU работало непрерывно… На самом деле нет! Работало еще как с прерываниями(не путать с теми, которые interrupt), просто настолько быстро, что мы были неспособны это осознать, а для того, чтобы успевали работать фоновые службы, приложения и что бы то ни было ещё как раз и придумали многозадачность !
https://habr.com/ru/articles/1024868/
#assembler #go #multithreading #multitasking #race_condition #cache_contention #cpu #ram #linux
-
Деконструкция GO: CPU, RAM и что там происходит. Многозадачность, многопоточность, кэши, проблемы. Часть 1.2
В прошлой статье я немного слукавил, сказав, что мы будем разбирать атомики, барьеры и системные вызовы. Я пару дней поразмышлял и осознал – а зачем вообще это объяснять, если мы даже не знаем про причину их возникновения и проблемы, которые они решают В части 1.1 мы рассмотрели базовые инструкции, которые выполняет наш CPU и которыми в конечном счете и являются наши прекрасные строчки на Go. Но возникает закономерный вопрос: “Окей, мы поняли как работает на одном ядре, но Go у нас во многом про многопоточку, соответственно как это будет работать на нескольких потоках?” Если что, то это часть большого цикла по разбору Go! Данная статья – это подводка уже к тому, с чем мы имеем дело в Go достаточно часто(барьеры памяти, атомики, сисколы) В этот раз будет без Go Assembler, но с +- реальными примерами, если что-то непонятно будет, то на Хабре есть классный ИИ-помощник Многозадачность Хоть мы и развенчиваем в этом цикле абстракции, придется немного к ним вернуться. Но ненадолго! Вспоминаем, как у нас выполняются инструкции в процессоре и представляем следующую конфигурацию: Есть какое-то количество ГБ RAM Есть 1 ядро CPU Соответственно в один момент CPU может выполнять ровно 1 набор инструкций Но почему-то всё во времена одноядерных CPU работало непрерывно… На самом деле нет! Работало еще как с прерываниями(не путать с теми, которые interrupt), просто настолько быстро, что мы были неспособны это осознать, а для того, чтобы успевали работать фоновые службы, приложения и что бы то ни было ещё как раз и придумали многозадачность !
https://habr.com/ru/articles/1024868/
#assembler #go #multithreading #multitasking #race_condition #cache_contention #cpu #ram #linux
-
Приложение real-time face swap на чистом Rust: ONNX Runtime, lock-free потоки и 60 кадров в секунду
Большинство инструментов для замены лиц это Python-скрипты, склеенные из PyTorch, OpenCV и надежды. Они работают, но тащат за собой гигабайты зависимостей, требуют правильно настроенного CUDA и разваливаются в тот момент, когда ты пытаешься запустить их в реальном времени. Мне стало интересно: можно ли собрать весь пайплайн на чистом Rust? Без Python. Без PyTorch. Без обёрток. Один бинарник, который скачал, распаковал и запустил. Оказалось, можно. 60 fps на веб-камере. Пайплайн На каждом кадре последовательно отрабатывают четыре нейросети. RetinaFace находит лица и извлекает пять ключевых точек. ArcFace вычисляет 512-мерный эмбеддинг исходного лица. InSwapper принимает регион целевого лица и эмбеддинг источника, на выходе отдаёт заменённое лицо. GFPGAN опционально улучшает результат для более высокого качества. Все четыре модели работают через ONNX Runtime. Никаких кастомных CUDA-ядер, никакого оверхеда фреймворков. Тензор на вход, тензор на выход. Архитектура потоков Три потока, ноль блокировок на горячем пути. Поток захвата получает кадры с веб-камеры через nokhwa и публикует их через ArcSwap. Поток пайплайна подхватывает новые кадры, прогоняет инференс и публикует обработанные кадры через второй ArcSwap. Поток UI читает актуальный буфер и рендерит через egui. Никаких мьютексов на данных кадра. Никаких каналов. Никакого async. Только атомарные счётчики поколений и lock-free замена указателей. Структуры разделяемого состояния занимают ровно по 64 байта каждая и выровнены по кэш-линиям, чтобы исключить false sharing между ядрами. Это проверяется compile-time ассертами.
https://habr.com/ru/articles/1024700/
#Rust #ONNX #Machine_Learning #Computer_Vision #Face_Detection #egui #Open_Source #lockfree #multithreading #realtime
-
Приложение real-time face swap на чистом Rust: ONNX Runtime, lock-free потоки и 60 кадров в секунду
Большинство инструментов для замены лиц это Python-скрипты, склеенные из PyTorch, OpenCV и надежды. Они работают, но тащат за собой гигабайты зависимостей, требуют правильно настроенного CUDA и разваливаются в тот момент, когда ты пытаешься запустить их в реальном времени. Мне стало интересно: можно ли собрать весь пайплайн на чистом Rust? Без Python. Без PyTorch. Без обёрток. Один бинарник, который скачал, распаковал и запустил. Оказалось, можно. 60 fps на веб-камере. Пайплайн На каждом кадре последовательно отрабатывают четыре нейросети. RetinaFace находит лица и извлекает пять ключевых точек. ArcFace вычисляет 512-мерный эмбеддинг исходного лица. InSwapper принимает регион целевого лица и эмбеддинг источника, на выходе отдаёт заменённое лицо. GFPGAN опционально улучшает результат для более высокого качества. Все четыре модели работают через ONNX Runtime. Никаких кастомных CUDA-ядер, никакого оверхеда фреймворков. Тензор на вход, тензор на выход. Архитектура потоков Три потока, ноль блокировок на горячем пути. Поток захвата получает кадры с веб-камеры через nokhwa и публикует их через ArcSwap. Поток пайплайна подхватывает новые кадры, прогоняет инференс и публикует обработанные кадры через второй ArcSwap. Поток UI читает актуальный буфер и рендерит через egui. Никаких мьютексов на данных кадра. Никаких каналов. Никакого async. Только атомарные счётчики поколений и lock-free замена указателей. Структуры разделяемого состояния занимают ровно по 64 байта каждая и выровнены по кэш-линиям, чтобы исключить false sharing между ядрами. Это проверяется compile-time ассертами.
https://habr.com/ru/articles/1024700/
#Rust #ONNX #Machine_Learning #Computer_Vision #Face_Detection #egui #Open_Source #lockfree #multithreading #realtime
-
Приложение real-time face swap на чистом Rust: ONNX Runtime, lock-free потоки и 60 кадров в секунду
Большинство инструментов для замены лиц это Python-скрипты, склеенные из PyTorch, OpenCV и надежды. Они работают, но тащат за собой гигабайты зависимостей, требуют правильно настроенного CUDA и разваливаются в тот момент, когда ты пытаешься запустить их в реальном времени. Мне стало интересно: можно ли собрать весь пайплайн на чистом Rust? Без Python. Без PyTorch. Без обёрток. Один бинарник, который скачал, распаковал и запустил. Оказалось, можно. 60 fps на веб-камере. Пайплайн На каждом кадре последовательно отрабатывают четыре нейросети. RetinaFace находит лица и извлекает пять ключевых точек. ArcFace вычисляет 512-мерный эмбеддинг исходного лица. InSwapper принимает регион целевого лица и эмбеддинг источника, на выходе отдаёт заменённое лицо. GFPGAN опционально улучшает результат для более высокого качества. Все четыре модели работают через ONNX Runtime. Никаких кастомных CUDA-ядер, никакого оверхеда фреймворков. Тензор на вход, тензор на выход. Архитектура потоков Три потока, ноль блокировок на горячем пути. Поток захвата получает кадры с веб-камеры через nokhwa и публикует их через ArcSwap. Поток пайплайна подхватывает новые кадры, прогоняет инференс и публикует обработанные кадры через второй ArcSwap. Поток UI читает актуальный буфер и рендерит через egui. Никаких мьютексов на данных кадра. Никаких каналов. Никакого async. Только атомарные счётчики поколений и lock-free замена указателей. Структуры разделяемого состояния занимают ровно по 64 байта каждая и выровнены по кэш-линиям, чтобы исключить false sharing между ядрами. Это проверяется compile-time ассертами.
https://habr.com/ru/articles/1024700/
#Rust #ONNX #Machine_Learning #Computer_Vision #Face_Detection #egui #Open_Source #lockfree #multithreading #realtime
-
Приложение real-time face swap на чистом Rust: ONNX Runtime, lock-free потоки и 60 кадров в секунду
Большинство инструментов для замены лиц это Python-скрипты, склеенные из PyTorch, OpenCV и надежды. Они работают, но тащат за собой гигабайты зависимостей, требуют правильно настроенного CUDA и разваливаются в тот момент, когда ты пытаешься запустить их в реальном времени. Мне стало интересно: можно ли собрать весь пайплайн на чистом Rust? Без Python. Без PyTorch. Без обёрток. Один бинарник, который скачал, распаковал и запустил. Оказалось, можно. 60 fps на веб-камере. Пайплайн На каждом кадре последовательно отрабатывают четыре нейросети. RetinaFace находит лица и извлекает пять ключевых точек. ArcFace вычисляет 512-мерный эмбеддинг исходного лица. InSwapper принимает регион целевого лица и эмбеддинг источника, на выходе отдаёт заменённое лицо. GFPGAN опционально улучшает результат для более высокого качества. Все четыре модели работают через ONNX Runtime. Никаких кастомных CUDA-ядер, никакого оверхеда фреймворков. Тензор на вход, тензор на выход. Архитектура потоков Три потока, ноль блокировок на горячем пути. Поток захвата получает кадры с веб-камеры через nokhwa и публикует их через ArcSwap. Поток пайплайна подхватывает новые кадры, прогоняет инференс и публикует обработанные кадры через второй ArcSwap. Поток UI читает актуальный буфер и рендерит через egui. Никаких мьютексов на данных кадра. Никаких каналов. Никакого async. Только атомарные счётчики поколений и lock-free замена указателей. Структуры разделяемого состояния занимают ровно по 64 байта каждая и выровнены по кэш-линиям, чтобы исключить false sharing между ядрами. Это проверяется compile-time ассертами.
https://habr.com/ru/articles/1024700/
#Rust #ONNX #Machine_Learning #Computer_Vision #Face_Detection #egui #Open_Source #lockfree #multithreading #realtime
-
Found a Rust library to send messages between threads! 🦀
🌀 **flume** — A safe and fast multi-producer, multi-consumer channel.
💯 Drop-in replacement for std::sync::mpsc with MPMC support and async APIs
⭐ GitHub: https://github.com/zesterer/flume
#rustlang #rust #concurrency #multithreading #systems #programming #opensource #tips #library
-
Found a Rust library to send messages between threads! 🦀
🌀 **flume** — A safe and fast multi-producer, multi-consumer channel.
💯 Drop-in replacement for std::sync::mpsc with MPMC support and async APIs
⭐ GitHub: https://github.com/zesterer/flume
#rustlang #rust #concurrency #multithreading #systems #programming #opensource #tips #library
-
Found a Rust library to send messages between threads! 🦀
🌀 **flume** — A safe and fast multi-producer, multi-consumer channel.
💯 Drop-in replacement for std::sync::mpsc with MPMC support and async APIs
⭐ GitHub: https://github.com/zesterer/flume
#rustlang #rust #concurrency #multithreading #systems #programming #opensource #tips #library
-
Found a Rust library to send messages between threads! 🦀
🌀 **flume** — A safe and fast multi-producer, multi-consumer channel.
💯 Drop-in replacement for std::sync::mpsc with MPMC support and async APIs
⭐ GitHub: https://github.com/zesterer/flume
#rustlang #rust #concurrency #multithreading #systems #programming #opensource #tips #library
-
Found a Rust library to send messages between threads! 🦀
🌀 **flume** — A safe and fast multi-producer, multi-consumer channel.
💯 Drop-in replacement for std::sync::mpsc with MPMC support and async APIs
⭐ GitHub: https://github.com/zesterer/flume
#rustlang #rust #concurrency #multithreading #systems #programming #opensource #tips #library
-
https://www.europesays.com/ie/373669/ Read-Copy-Update (RCU): The Secret to Lock-Free Performance #Architecture #Architecture&Design #Arts #ArtsAndDesign #ArtsAndDesign #ArtsDesign #Concurrency #Design #Development #Éire #Entertainment #IE #Ireland #MultiThreading #performance #Performance&Scalability #ReadCopyUpdate
-
Unlock unmatched read scalability with #ReadCopyUpdate (RCU) – a lock-free approach that outperforms traditional reader-writer locks in read-heavy workloads.
This #InfoQ article by Ramesh Sinha explains how RCU works, where it shines, and how to apply it.
📖 Read now: https://bit.ly/4rW7CV7
#SoftwareArchitecture #Performance #Concurrency #Scalability #MultiThreading
-
Unlock unmatched read scalability with #ReadCopyUpdate (RCU) – a lock-free approach that outperforms traditional reader-writer locks in read-heavy workloads.
This #InfoQ article by Ramesh Sinha explains how RCU works, where it shines, and how to apply it.
📖 Read now: https://bit.ly/4rW7CV7
#SoftwareArchitecture #Performance #Concurrency #Scalability #MultiThreading
-
Unlock unmatched read scalability with #ReadCopyUpdate (RCU) – a lock-free approach that outperforms traditional reader-writer locks in read-heavy workloads.
This #InfoQ article by Ramesh Sinha explains how RCU works, where it shines, and how to apply it.
📖 Read now: https://bit.ly/4rW7CV7
#SoftwareArchitecture #Performance #Concurrency #Scalability #MultiThreading
-
Unlock unmatched read scalability with #ReadCopyUpdate (RCU) – a lock-free approach that outperforms traditional reader-writer locks in read-heavy workloads.
This #InfoQ article by Ramesh Sinha explains how RCU works, where it shines, and how to apply it.
📖 Read now: https://bit.ly/4rW7CV7
#SoftwareArchitecture #Performance #Concurrency #Scalability #MultiThreading
-
Unlock unmatched read scalability with #ReadCopyUpdate (RCU) – a lock-free approach that outperforms traditional reader-writer locks in read-heavy workloads.
This #InfoQ article by Ramesh Sinha explains how RCU works, where it shines, and how to apply it.
📖 Read now: https://bit.ly/4rW7CV7
#SoftwareArchitecture #Performance #Concurrency #Scalability #MultiThreading
-
[Перевод] Async Coalescing: 5 стратегий объединения асинхронных запросов
Асинхронное программирование сегодня используется почти везде — от пользовательских интерфейсов до серверных систем с высокой нагрузкой. Оно позволяет не блокировать поток выполнения и эффективно работать с операциями ввода-вывода. Но вместе с этой гибкостью появляется и обратная сторона: пересекающиеся асинхронные вызовы начинают конкурировать друг с другом. Представим простой пример. Пользователь печатает в строке поиска, и каждый символ запускает новый запрос. Или серверный сервис несколько раз запрашивает одни и те же данные, потому что разные части системы одновременно обращаются к одному ресурсу. Это не редкие случаи — такое происходит постоянно. Если такие вызовы никак не координировать, система начинает выполнять лишнюю работу. Возникают дублирующиеся запросы, гонки данных и дополнительные вычисления. В интерфейсах результаты могут приходить в неправильном порядке, а на сервере растёт нагрузка и появляются трудно воспроизводимые ошибки. Обычно проблему пытаются решать блокировками, токенами отмены или дополнительными проверками в коде, но такие решения часто оказываются лишь временными костылями. Более системный подход — объединять пересекающиеся асинхронные операции. Если несколько вызовов требуют один и тот же результат, нет необходимости выполнять работу несколько раз. Гораздо разумнее выполнить её один раз и распределить результат между всеми ожидающими. Однако в реальных системах одного такого поведения недостаточно. Иногда результат должен определяться самым последним запросом. Иногда выполнение лучше немного отложить, чтобы дождаться стабилизации входных данных. А в некоторых случаях операции вообще нужно выполнять строго по очереди. В этой статье я разберу пять стратегий Async Coalescing — подхода, который позволяет контролировать конкуренцию асинхронных операций. Мы посмотрим, в каких ситуациях каждая стратегия полезна и какие компромиссы она вносит в систему.
-
[Перевод] Async Coalescing: 5 стратегий объединения асинхронных запросов
Асинхронное программирование сегодня используется почти везде — от пользовательских интерфейсов до серверных систем с высокой нагрузкой. Оно позволяет не блокировать поток выполнения и эффективно работать с операциями ввода-вывода. Но вместе с этой гибкостью появляется и обратная сторона: пересекающиеся асинхронные вызовы начинают конкурировать друг с другом. Представим простой пример. Пользователь печатает в строке поиска, и каждый символ запускает новый запрос. Или серверный сервис несколько раз запрашивает одни и те же данные, потому что разные части системы одновременно обращаются к одному ресурсу. Это не редкие случаи — такое происходит постоянно. Если такие вызовы никак не координировать, система начинает выполнять лишнюю работу. Возникают дублирующиеся запросы, гонки данных и дополнительные вычисления. В интерфейсах результаты могут приходить в неправильном порядке, а на сервере растёт нагрузка и появляются трудно воспроизводимые ошибки. Обычно проблему пытаются решать блокировками, токенами отмены или дополнительными проверками в коде, но такие решения часто оказываются лишь временными костылями. Более системный подход — объединять пересекающиеся асинхронные операции. Если несколько вызовов требуют один и тот же результат, нет необходимости выполнять работу несколько раз. Гораздо разумнее выполнить её один раз и распределить результат между всеми ожидающими. Однако в реальных системах одного такого поведения недостаточно. Иногда результат должен определяться самым последним запросом. Иногда выполнение лучше немного отложить, чтобы дождаться стабилизации входных данных. А в некоторых случаях операции вообще нужно выполнять строго по очереди. В этой статье я разберу пять стратегий Async Coalescing — подхода, который позволяет контролировать конкуренцию асинхронных операций. Мы посмотрим, в каких ситуациях каждая стратегия полезна и какие компромиссы она вносит в систему.
-
[Перевод] Async Coalescing: 5 стратегий объединения асинхронных запросов
Асинхронное программирование сегодня используется почти везде — от пользовательских интерфейсов до серверных систем с высокой нагрузкой. Оно позволяет не блокировать поток выполнения и эффективно работать с операциями ввода-вывода. Но вместе с этой гибкостью появляется и обратная сторона: пересекающиеся асинхронные вызовы начинают конкурировать друг с другом. Представим простой пример. Пользователь печатает в строке поиска, и каждый символ запускает новый запрос. Или серверный сервис несколько раз запрашивает одни и те же данные, потому что разные части системы одновременно обращаются к одному ресурсу. Это не редкие случаи — такое происходит постоянно. Если такие вызовы никак не координировать, система начинает выполнять лишнюю работу. Возникают дублирующиеся запросы, гонки данных и дополнительные вычисления. В интерфейсах результаты могут приходить в неправильном порядке, а на сервере растёт нагрузка и появляются трудно воспроизводимые ошибки. Обычно проблему пытаются решать блокировками, токенами отмены или дополнительными проверками в коде, но такие решения часто оказываются лишь временными костылями. Более системный подход — объединять пересекающиеся асинхронные операции. Если несколько вызовов требуют один и тот же результат, нет необходимости выполнять работу несколько раз. Гораздо разумнее выполнить её один раз и распределить результат между всеми ожидающими. Однако в реальных системах одного такого поведения недостаточно. Иногда результат должен определяться самым последним запросом. Иногда выполнение лучше немного отложить, чтобы дождаться стабилизации входных данных. А в некоторых случаях операции вообще нужно выполнять строго по очереди. В этой статье я разберу пять стратегий Async Coalescing — подхода, который позволяет контролировать конкуренцию асинхронных операций. Мы посмотрим, в каких ситуациях каждая стратегия полезна и какие компромиссы она вносит в систему.
-
[Перевод] Async Coalescing: 5 стратегий объединения асинхронных запросов
Асинхронное программирование сегодня используется почти везде — от пользовательских интерфейсов до серверных систем с высокой нагрузкой. Оно позволяет не блокировать поток выполнения и эффективно работать с операциями ввода-вывода. Но вместе с этой гибкостью появляется и обратная сторона: пересекающиеся асинхронные вызовы начинают конкурировать друг с другом. Представим простой пример. Пользователь печатает в строке поиска, и каждый символ запускает новый запрос. Или серверный сервис несколько раз запрашивает одни и те же данные, потому что разные части системы одновременно обращаются к одному ресурсу. Это не редкие случаи — такое происходит постоянно. Если такие вызовы никак не координировать, система начинает выполнять лишнюю работу. Возникают дублирующиеся запросы, гонки данных и дополнительные вычисления. В интерфейсах результаты могут приходить в неправильном порядке, а на сервере растёт нагрузка и появляются трудно воспроизводимые ошибки. Обычно проблему пытаются решать блокировками, токенами отмены или дополнительными проверками в коде, но такие решения часто оказываются лишь временными костылями. Более системный подход — объединять пересекающиеся асинхронные операции. Если несколько вызовов требуют один и тот же результат, нет необходимости выполнять работу несколько раз. Гораздо разумнее выполнить её один раз и распределить результат между всеми ожидающими. Однако в реальных системах одного такого поведения недостаточно. Иногда результат должен определяться самым последним запросом. Иногда выполнение лучше немного отложить, чтобы дождаться стабилизации входных данных. А в некоторых случаях операции вообще нужно выполнять строго по очереди. В этой статье я разберу пять стратегий Async Coalescing — подхода, который позволяет контролировать конкуренцию асинхронных операций. Мы посмотрим, в каких ситуациях каждая стратегия полезна и какие компромиссы она вносит в систему.
-
I want to add #multithreading in my custom language compiler.
When run it currently compiles all source files one-by-one, but I feel like I could run 3 threads and each can compile a third of the source files, similar to the "-j" argument in #make .
I don't want to deal with thread-related errors though ..
-
I want to add #multithreading in my custom language compiler.
When run it currently compiles all source files one-by-one, but I feel like I could run 3 threads and each can compile a third of the source files, similar to the "-j" argument in #make .
I don't want to deal with thread-related errors though ..
-
Вытесняй и властвуй: еще раз про многозадачность
В последнее время мне довелось много заниматься распараллеливанием однопоточного кода и показалось уместным свести воедино более-менее всё, что нам известно про разные типы многозадачности, с примерами и комментариями. Примеры на Ruby, Go, Java.
-
Вытесняй и властвуй: еще раз про многозадачность
В последнее время мне довелось много заниматься распараллеливанием однопоточного кода и показалось уместным свести воедино более-менее всё, что нам известно про разные типы многозадачности, с примерами и комментариями. Примеры на Ruby, Go, Java.
-
Вытесняй и властвуй: еще раз про многозадачность
В последнее время мне довелось много заниматься распараллеливанием однопоточного кода и показалось уместным свести воедино более-менее всё, что нам известно про разные типы многозадачности, с примерами и комментариями. Примеры на Ruby, Go, Java.
-
Вытесняй и властвуй: еще раз про многозадачность
В последнее время мне довелось много заниматься распараллеливанием однопоточного кода и показалось уместным свести воедино более-менее всё, что нам известно про разные типы многозадачности, с примерами и комментариями. Примеры на Ruby, Go, Java.
-
Три модели многопоточности: Event Loop, Platform Threads и Virtual Threads
Разные языки пришли к разным моделям многопоточности и каждая решает проблему по-своему. Разбираем специфику каждой модели.
https://habr.com/ru/articles/991162/
#java #spring #spring_boot #spring_framework #springboot #многопоточность #multithreading
-
Три модели многопоточности: Event Loop, Platform Threads и Virtual Threads
Разные языки пришли к разным моделям многопоточности и каждая решает проблему по-своему. Разбираем специфику каждой модели.
https://habr.com/ru/articles/991162/
#java #spring #spring_boot #spring_framework #springboot #многопоточность #multithreading
-
Три модели многопоточности: Event Loop, Platform Threads и Virtual Threads
Разные языки пришли к разным моделям многопоточности и каждая решает проблему по-своему. Разбираем специфику каждой модели.
https://habr.com/ru/articles/991162/
#java #spring #spring_boot #spring_framework #springboot #многопоточность #multithreading
-
Три модели многопоточности: Event Loop, Platform Threads и Virtual Threads
Разные языки пришли к разным моделям многопоточности и каждая решает проблему по-своему. Разбираем специфику каждой модели.
https://habr.com/ru/articles/991162/
#java #spring #spring_boot #spring_framework #springboot #многопоточность #multithreading
-
I’m heading to @ConFooCa 2026 in Montréal 🇨🇦 in a few weeks, where I’ll be speaking about two things I care a lot about in the PHP world: observability and multithreading.
If you’re going too, let’s connect! Always happy to chat observability, profilers, and real-world performance wins in PHP 🎉
-
I’m heading to @ConFooCa 2026 in Montréal 🇨🇦 in a few weeks, where I’ll be speaking about two things I care a lot about in the PHP world: observability and multithreading.
If you’re going too, let’s connect! Always happy to chat observability, profilers, and real-world performance wins in PHP 🎉
-
I’m heading to @ConFooCa 2026 in Montréal 🇨🇦 in a few weeks, where I’ll be speaking about two things I care a lot about in the PHP world: observability and multithreading.
If you’re going too, let’s connect! Always happy to chat observability, profilers, and real-world performance wins in PHP 🎉
-
I’m heading to @ConFooCa 2026 in Montréal 🇨🇦 in a few weeks, where I’ll be speaking about two things I care a lot about in the PHP world: observability and multithreading.
If you’re going too, let’s connect! Always happy to chat observability, profilers, and real-world performance wins in PHP 🎉