Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Темы
0 просмотренных постов скрыто

Многопоточный санузел⁠⁠

Когда я забеременела вторым ребенком в 2022-ом, продемонстрировала, счастливая, мужу тест с двумя яркими красными полосками, муж сказал:

- Мне нужен психолог!

А дочь из комнаты крикнула:

- Ноги его в моей комнате не будет!

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

Но на одном понимании Скули не выедешь - необходимо было расширяться. И стала я проектировать пристройку к дому со стороны входа.

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

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

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

Только где проектировать вход в санузел? Второй этаж получается весь трамвайного типа! Поднимаешься по лестнице: направо к дочери, налево к нам. Все! Иных проходов нет. Пристройку для санузла и детской я разделила ровно на две части, детская примыкает к нашей спальне, санузел - формально к дочериной, но наша комната шире дочериной, поэтому стена санузла захватывает обе спальни. И получается, что оба входа - и в новую детскую, и в санузел - будут из нашей спальни! А если б даже и были бы наши две спальни по ширине одинаковые, и санузел строго примыкал бы только к дочериной комнате, все равно не удобно было бы нам всем ходить в санузел через дочь! Это издевательство было бы над ней. А так дочери бегать через нас? Ага!... А потом сын подрастет и тоже будет бегать через нас в туалет! (Мало того, что просто проход в его комнату через нас) Никакой личной жизни?!

Вот поэтому я и не стала мелочиться: я спроектировала вход в санузел из КАЖДОЙ спальни! И из нашей, и из дочериной, и из новостроеной комнаты сына!

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

- Это что вы все вот так здесь по кругу ходить будете, что ли?!

Ага. Зашли в дочерину комнату, прошли в санузел, зашли из него к сыночку, вышли к нам в спальню и пошли обратно к дочери. Все взялись за руки и ходим! Делать нам больше нечего... Как же они не поняли мою гениальную задумку?! Мой СУПЕР-ПРОЕКТ!... Недооцененный.

А дочь с мужем до сих пор ржут надо мной! Потому что это наглядная демонстрация data race: точку доступа открыли трем потокам, а мьютексы на чтение и запись поставить забыли! Тут или пул бюрократии, чтобы сходить поссать: сначала надо постучать и запросить разрешение на транзакцию (не ссыт ли кто в данный момент?), затем отправить всем трем потокам пуш-уведомление (шпингалеты или таблички) о том, что в данный момент идет активная транзакция, потом не забыть отправить обратные пуш-уведомления (три таблички снять или разблокировать шпингалеты), что транзакция завершена, можно заходить другому потоку, или будут дед-локи (например дочь три шпингалета закрыла, а потом открыла только свой, и в туалет, кроме как через ее комнату, больше никому не попасть), или та самая дата-рейс!

Тут доработать-то... Что два пальца об асфальт!

Варианты решения

  • Общий мьютекс. mutex.lock(), mutex.unlock(). Ну просто шпингалетики ставим и троссиками их соединяем! Делов-то? Закрываешь один шпингалет, троссики натягиваются, шестеренки шуршат, и закрываются остальные! А Ганс Форальберг нервно курит в сторонке.

  • Обернуть наш сортир в std::atomic. Ну унитаз и так атомарен по определению, в него не могут физически посрать два человека одновременно. Осталось разобраться с ванной, с раковиной... Как-то сделать их неделимыми вместе с унитазом! Например тройной клапан подачи воды и слива: перекрывает все так, что слив и вода свободны либо только для унитаза, либо только для раковины, либо только для ванны. Тогда нарушить атомарность не будет ни для кого никакого стимула! Все будут об этом помнить... Делов-то?

  • Спинлок в виде закольцованых датчиков под ковриками, которые подают сигнал и зажигают индикаторы красным в каждой комнате! (Желательно бы еще блокировать магнитными полями все двери).

  • std::queque. Вывесить табло электронной очереди перед пристройкой. Автоинформатор на весь этаж: «Талон с номером А4, пройдите к унитазу!»

И так как нам бюрократией заниматься лень, то у нас конечно же дата-рейс! Все двери открыты, ни шпингалетов, ни табличек, ни красно-зеленых световых индикаторов "занято\свободно", ни талонов МФЦ нет. Поэтому периодически у нас (если все дома) раздается или мужнино "Я сру! Сюда идти не надо!", или дочерин визг из ванны, а за ним визг домработницы, которая зашла помыть помещение, не постучав, или мое грозное "Ну кто опять убрал пандус?!"

Странно, и почему же надо мной вся семья ржет? Ведь я гениальный архитектор!

Показать полностью 2
[моё] C++ Многопоточность Юмор Разработка Строительство Истории из жизни Архитектор Проект Идея Длиннопост
18
12

Ищу общедоступный курс Concurrency за авторством Липовского Р. Г., 2022 г⁠⁠

Всем доброго времени суток! На канале Лекторий ФПМИ (YouTube) был прекрасный курс Concurrency с лекциями и семинарами за авторством Липовского Р. Г.  2022 г, в котором прекрасно объяснялись темы по использованию возможностей C++ для многопоточного и асинхронного исполнения программ. Хотел на новогодних каникулах подтятуть знания, но к сожалению видео с канала были удалены. Возможно, у кого-то есть резервные копии видео, прошу поделиться. Всем полезных новогодних праздников!

[моё] C++ Программирование Вопрос Спроси Пикабу Многопоточность Текст
8
3

Разбираем паттерны конкурентности⁠⁠

База

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

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

Процессы:

  • Раздельная память

  • Раздельные ресурсы

  • Раздельные регистры

Потоки:

  • Общая память

  • Общие ресурсы

  • Раздельные стэк и регистры

Горутины:

  • Общая память

  • Общие ресурсы

  • Общий системный стэк

  • Общие регистры

Go runtime представляет модель P:M:G.

P - представляет логическое ядро процессора.

M - поток ОС по числу процессоров P.

G - структура, которая выполняет переданную функцию, создаётся по необходимости, минимум одна на старте программы (main). Стэк всего 2кб, может расширятся до 1гб для 64x и до 250кб для 32х систем.

Управление горутинами осуществляется планировщиком Go, а не ОС. Планировщик Go работает в пользовательском пространстве. Мы не можем напрямую управлять на каком процессоре будет исполняться горутина, за это отвечает планировщик.

Канал - очередь сообщений, которая умеет работать в многопоточной среде, работает по принципу FIFO.

Есть два типа каналов: буферизованный и небуферизованный.

Первый может хранить несколько сообщений, второй только одно.

Синхронизация

sync.WaitGroup - счётчик, который позволяет подождать завершения горутин.

sync.Mutex - блокирует доступ к ресурсу.

sync.RwMutex - разделяемая блокировка на чтение и запись. Читать могут несколько горутин, но мутировать данные только одна.

sync.Atomic - атомарная операция чтения и записи. Работает только с простыми значениями.

sync.Map - lock-free структура. Работает так же, как и обычная map, но потокобезопасная, можно использовать в многопоточной среде. Хорошо подходит для случаев, где надо много читать и мало писать. Если надо много писать, то лучше использовать обычную map и sync.RwMutex.

Небуферизованный канал

Буферизованный канал

Ограничения канала

Важные правила

  • Закрывает канал тот, кто в него пишет.

  • Если пишет несколько продюсеров, то закрывает тот, кто создал продюсеров.

  • Не закрытый канал держит ресурсы. Закрывать надо явно.

Паттерны

Generator

Микропаттерн, который наполняет канал. Закрываем канал, чтобы не было проблем.

func generator() <- chan int {

ch := make(chant int)

go func(){

for i := 0; i <= 12; i++ {

ch <- i + 1

}

close(ch)

}()

return ch

}

Wrapper

Оборачиваем функцию, добавляя функциональность. Если вам что-то говорит слово декоратор, то это тот самый паттерн.

func wrapper(wg *sync.WaitGroup, fn func()) {

wg.Add(1)

go func() {

defer wg.Done()

fmt.Println("Work before func")

fn()

time.Sleep(1 * time.Second)

fmt.Println("Work after func")

}()

}

func main() {

var wg sync.WaitGroup

wrapper(&wg, func() {

time.Sleep(1 * time.Second)

fmt.Println("heavy work")

})

wg.Wait()

}

Fan-in

Собирает результаты из нескольких каналов в один.

func fanIn(input1, input2 <-chan string) <-chan string {

ch := make(chan string)

go func(){

for {

select {

case s := <-input1: ch <- s

case s := <-input2: ch <- s

}

}

}()

return ch

}

Fan-out

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

func worker(ch <-chan int, wg *sync.WaitGroup) {

wg.Done()

for v := range ch {

fmt.Println(v)

time.Sleep(1 * time.Second)

}

}

func sender() {

ch := make(chan int)

var wg sync.WaitGroup

for i := 0; i < 2; i++ {

wg.Add(1)

go worker(ch, &wg)

}

for i := 0; i < 10; i++ {

ch <- i

}

close(ch)

wg.Wait()

fmt.Println("done")

}

Pipeline

Данные обрабатываются цепочкой. Producer -> Producer/Consumer -> Consumer. Стадий обработки может быть сколько угодно.

func producer() <-chan int {

c := make(chan int)

go func() {

for i := 0; i <= 10; i++ {

c <- i + 1

}

close(c)

}()

return c

}

func producerConsumer(c <-chan int) <-chan int {

out := make(chan int)

go func() {

for v := range c {

out <- v * 2

}

close(out)

}()

return out

}

func consumer(ch <-chan int) {

for v := range ch {

fmt.Println(v)

}

}

Rate limiting

Хотя для rate limiter есть множество разных алгоритмов, рассмотрим один, основанный на тиках.

func ticker() {

ch := make(chan int, 5)

go func() {

for i := 0; i < 5; i++ {

ch <- i

}

close(ch)

}()

limiter := time.Tick(time.Second)

for v := range ch {

<-limiter // будем ждать секунду

fmt.Println(v)

}

}

Cancellation

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

1. WithCancel

func worker(ctx context.Context) {

for {

select {

case <-ctx.Done():

fmt.Println("Done")

return

default:

fmt.Println("Working...")

time.Sleep(500 * time.Millisecond)

}

}

}

func main() {

ctx, cancel := context.WithCancel(context.Background())

go worker(ctx)

time.Sleep(1 * time.Second) // работаем

cancel() // отменяем

time.Sleep(1 * time.Second) // время на завершение

}

2. WithTimeout

ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second) // спустя 2 секунды воркер перестанет работать

3. WithDeadline. Можно указать точное время остановки.

ctx, cancel := context.WithDeadline(context.Background(), time.Now().Add(2*time.Second)) // прибавляем к текущему времени две секунды

Worker Pool

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

func worker(jobs <-chan int, results chan<- int, wg *sync.WaitGroup) {

defer wg.Done()

for j := range jobs {

time.Sleep(1 * time.Second)

fmt.Println("job", j)

results <- j * j

}

}

func main() {

jobs := make(chan int)

results := make(chan int)

var wg sync.WaitGroup

for i := 0; i < 3; i++ {

wg.Add(1)

go worker(jobs, results, &wg)

}

go func() {

for i := 0; i < 10; i++ {

jobs <- i

}

close(jobs)

}()

go func() {

wg.Wait()

close(results)

}()

for result := range results {

fmt.Println(result)

}

}

Actor model

Паттерн, при котором акторы общаются только через каналы, и меняют данные только через каналы.

type message struct {

amount int

response chan int

}

func counter(messages chan message) {

for m := range messages {

m.response <- m.amount + 1

close(m.response)

}

}

func main() {

messages := make(chan message)

var wg sync.WaitGroup

go counter(messages)

wg.Add(3)

for i := 0; i < 3; i++ {

go func(i int) {

defer wg.Done()

response := make(chan int)

messages <- message{amount: i, response: response}

fmt.Println(<-response)

}(i)

}

wg.Wait()

close(messages)

}

Это не все паттерны, их целая куча, но уже с этими можно делать интересные вещи, такие как балансировщики нагрузки, pub/sub системы, очереди задач, rate limiter и много всего другого.

Показать полностью 3
[моё] Программирование Golang Многопоточность Backend IT Длиннопост
3
0

Dead lock⁠⁠

Перед тем, как разобрать, что такое live lock, вспомним, что такое dead lock.

Deadlock bug на простейшем примере
Два потока захватывают мьютексы в разном порядке. Это может привести к ситуации, что планировщик запустит на выполнение поток 1, поток 1 захватит мьютекс 1, после чего планировщик приостановит выполнение потока 1 и запустит на выполнение поток 2. Поток 2 захватит мьютекс 2. Независимо от того, какой поток будет выполняться дальше, программа зависнет, т.к. потоки будут ждать разблокировки мьютексов (поток 1 - мьютека 2, поток 2 - мьютека 1), которая никогда не произойдет.

#include <iostream>
#include <thread>
#include <mutex>

void thread1(std::mutex& mutex1, std::mutex& mutex2)
{
std::lock_guard<std::mutex> lock1(mutex1);
std::cout << "Thread 1 acquired mutex1\n";

std::lock_guard<std::mutex> lock2(mutex2);
std::cout << "Thread 1 acquired mutex2\n";
}

void thread2(std::mutex& mutex1, std::mutex& mutex2)
{
std::lock_guard<std::mutex> lock2(mutex2);
std::cout << "Thread 2 acquired mutex2\n";

std::lock_guard<std::mutex> lock1(mutex1);
std::cout << "Thread 2 acquired mutex1\n";
}

int main()
{
std::mutex mutex1;
std::mutex mutex2;

std::thread t1(thread1, std::ref(mutex1), std::ref(mutex2));
std::thread t2(thread2, std::ref(mutex1), std::ref(mutex2));

t1.join();
t2.join();
}

Fix dead lock bug
В современном C++ баг, описанный выше, исправляется с помощью использования std::scoped_lock

#include <iostream>
#include <thread>
#include <mutex>

void thread1(std::mutex& mutex1, std::mutex& mutex2)
{
const std::scoped_lock lock(mutex1, mutex2);
std::cout << "Thread 1 acquired mutex1 and mutex2\n";
}

void thread2(std::mutex& mutex1, std::mutex& mutex2)
{
const std::scoped_lock lock(mutex1, mutex2);
std::cout << "Thread 2 acquired mutex1 and mutex2\n";
}

int main()
{
std::mutex mutex1;
std::mutex mutex2;

std::thread t1(thread1, std::ref(mutex1), std::ref(mutex2));
std::thread t2(thread2, std::ref(mutex1), std::ref(mutex2));

t1.join();
t2.join();
}

Больше технических постов тут t.me/neverending_cpp

Показать полностью
[моё] Кросспостинг Pikabu Publish Bot Текст C++ IT Многопоточность Deadlock
9
0

Скрытые возможности управления памятью в высокоуровневых языках: секреты, которые знают немногие⁠⁠

Серия PHP и веб-разработка: полезные руководства и совет

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

Гайд: "Неизвестные фишки управления памятью в высокоуровневых языках"

1. Ленивые вычисления (Lazy Evaluation) в неожиданных местах

Некоторые языки, такие как Haskell или Python (с функцией generator), используют ленивые вычисления, когда результат не вычисляется, пока он не станет необходим. Однако это можно внедрить в повседневные задачи в других языках, таких как JavaScript или даже Java. Как использовать ленивые вычисления для оптимизации кода, который работает с большими массивами данных?

Пример для Python:

def lazy_range(n):

i = 0

while i < n:

yield i

i += 1

Где применить: Для задач, где ты работаешь с большими последовательностями данных, но хочешь минимизировать использование памяти.

Скрытые возможности управления памятью в высокоуровневых языках: секреты, которые знают немногие

2. Эффективное использование кэширования с WeakRef

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

Python:

import weakref

class MyClass:

pass

obj = MyClass()

weak_obj = weakref.ref(obj)

Где применить: В местах, где требуется держать ссылки на объекты, но не перегружать память.

3. Аллокация памяти под многопоточность

В языках, как C++ и Rust, можно контролировать не только, как выделяется память, но и как она освобождается в многопоточном окружении. Даже в высокоуровневых языках, например, в Go или Kotlin, есть инструменты управления аллокацией памяти, о которых мало кто задумывается.

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

4. Принципы оптимизации памяти для асинхронного программирования

Асинхронность может вызвать утечку памяти, если неправильно управлять контекстами выполнения. Как избежать типичных ошибок в управлении памятью при использовании async/await в JavaScript или Python.

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

5. Функции с разбором мусора (Garbage Collection) в недокументированных языках

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

Инсайт: Тонкая настройка алгоритма Garbage Collection, оптимизированная под типы задач.

6. Контроль за аллокацией стека и кучи на уровне сборки

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

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

Важность:

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

Показать полностью 1
Многопоточность Инженер Станок Промышленность Длиннопост
0
30

Делаю курс по многопоточному и асинхронному программированию на Python⁠⁠

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

https://stepik.org/course/172356/promo

[моё] Обратная связь Многопоточность Курс Текст
7
0

Максимальное количество потоков Delphi⁠⁠

Здравствуйте!

Создаю задачи TTask в цикле. Всего должно быть 56, но создаются 23. Почему так может быть? При этом чем меньше кода в потоке, тем больше потоков удаётся создать. К примеру, если все потоки пустые и просто ждут (while true sleep...), то все создаются без проблем.

Вопрос Программирование Delphi Многопоточность Текст
18
1067

Геометрическое ядро САПР программ нового поколения⁠⁠

Для начала немного истории, все программы автоматизированного проектирования в том или ином виде берут свое начало с конца прошлого тысячелетия, а именно:

Autocad - 1982 г.

Revit - 1997 г.

Tekla - 1966 г.

Компас  - 1997 г.

Allplan - 1982 г.

ArchiCad - 1986 г.

Solidworks - 1993 г.

И многие иные, даже сложные комплексы для расчетов такие как ANSYS и ABAQUS созданы в конце прошлого столетия.

Из отечественных можно еще выделить Renga , но она создается на старом ядре C3D компании АСКОН, а они в свою очередь создатели Компаса, поэтому это одно и тоже решение в разных обёртках.


Все данные САПР программы объединены одним общим принципом, они все создавались на основе одного принципа обработки информации - последовательного, это было следствием реалий тех времён, не существовало аппаратных устройств многопоточной обработки информации. Но времена идут, всё меняется , но не меняются геометрические ядра. В среднем на создание полноценной САПР программы уходит от 5 до 7 лет и довольного большого числа сотрудников - разработчики, тестировщики, консультанты и т.д. и в текущих реалиях ни одна из компаний разработчиков не пойдет на полноценную перепись с нуля своих геометрических ядер под многопоточные CPU и GPU. Конечно, программы обновляются с каждым годом, но все данные нововведения по сути косметические без глубокой оптимизации.


В прошлом году я разместил пост в котором продемонстрировал возможности Unreal Engine 5 при отображении многомиллиардно полигональной геометрии. В течении последнего года я вел разработку геометрического ядра которое сможет использовать многопоточную обработку на CPU - процессов требующих двойной точности, а на GPU - процессов где хватает и одинарной точности. Новые видео карты Nvidia - 3070, 3080, 3090 уже способны находить решения с двойной точностью на тензорных ядрах (они используются при обработки трассировки лучей в играх)  , но на данный момент у меня работа с данными ядрами на этапе экспериментов.


По сути получилось решение которое по производительности превышает любую программу выше в списке от 10 до 100 раз и более. И это касается любых действий, отображение графики, копирования, изменений, перемещений, подсчета материалов и т.д.:

https://www.youtube.com/watch?v=cmcsxwrDo3o

В моем решение используется ровно такой же подход как в Unreal Engine 5 в технологии nanite. При удалении камеры пользователя происходит постепенная эрозия геометрии и упрощение геометрии вплоть до отображения одного пикселя, что позволяет отображать многократно больший объем информации по сравнению с программами "пенсионерами". Но у технологии Nanite есть один большой минус, необходимо предварительное кэширование шейдерных текстур на жёсткий диск , в САПР это невозможно , поэтому мне пришлось данную технологию переработать под САПР и особенно под армирование строительных конструкций и впереди еще много работы.

Показать полностью 1
[моё] САПР Bim Многопоточность Видео YouTube
95
Посты не найдены

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества

Недвижимость и ремонт

Теги

Популярные авторы

Сообщества