== Лекция 2. Корректная работа с потоками
https://youtu.be/qA5XLTxmsP0

join ждет когда завершится тот поток который передали

что бы остановить поток раньше - послать сигнал ему

NPTL - Native Posix Threads Library

ps покажет процессы
ps -m еще покажет и потоки

user-space переходит kernel-space для того что бы спланировать/управлять новый поток (потоками заведует ОС, ОС имеет защищенную модель памяти, владеет единолично этими данными) - стараться избегать переходов

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

поток проверяет у себя pthread_test_cancel() и если флаг выставлен то поток завершится.

pthread_cleanup_push(*f)
pthread_test_cancel()
pthread_cleanup_pop(*f)
- формирование стэка функций для корректного завершения потока (освободить ресурсы например). если был вызван pthread_test_cancel

cancelation_point - может завершить текущий поток, договоренность

любой syscall может завершить поток

каждый вызов test_cacnel совершает переход в кернел = медленно!

НО можно сказать что он не хочет быть завершен ! есть флаг

== Лекция 3. Примитивы синхронизации
https://youtu.be/kNWSciQtHEc

MUTEX - mutual exclusion - взаимное исключение
pthread_mutex_* ВСЕГДА переводит в кернел = МЕДЛЕННО !

recursive_mutex
+ можно захватить в рамках одного потока НЕСКОЛЬКО раз (в обычном только один раз)

timed_mutex
+ захватить с ограничением по временем (типа если не удалось захватить на 10мс то не очень то и хотелось)

shared_mutex
+ захват на чтение
+ захват на чтение с возмоностью дозахвата на запись

spin_mutex
+ активное ожидание в захвате => НЕ ПРОВАЛИВАЕТСЯ В КЕРНЕЛ = бесконечный цикл в одном потоке
atomic_cas
оч полезно когда работаешь с примитивами
+ меньше вероятность блокировки при мелких операциях

CAS - Compare-and-set - compare-and-swap
и сравнивает и пытается записать если успешно. АТОМАРНА НА УРОВНЕ ПРОЦЕССОРА и возвращает успех (x86 cmpxchg)

два потока войдут в одно место НО ТОЛЬКО ОДИН сможет выполнить CAS операцию и получит там успех. поэтому второй пойдет на повторный цикл

Futex - fast userspace muTexes
Те операции которые могут быть в юзерспейсе - идут в юзерспейсе, а если не могут быть - проваливаются в кернел.
(тоже реализованы на CAS)

== Лекция 4. Condition variables. Алгоритмы синхронизации
https://youtu.be/79d5WI5RTp8
лениризуемость программы - это код который может дать одни и те же результаты при последовательном так и при паралелльном исполнении

🔧 А вы знали, что в authorized_keys файле можно указывать не только сам ключ, но и дополнительные команды, или ограничения? Чуть подробнее об этом вот здесь: https://twitter.com/cyb3rops/status/1395009709787258882

А вообще, увидел я это в очередном, казалось бы, очевидном мануале по усилению безопасности SSH: https://blog.zsec.uk/locking-down-ssh-the-right-way/

#ssh #security #напочитать

Ого какую вещь я не замечал.

Easy and simple Prometheus SLO (service level objectives) generator

https://github.com/slok/sloth

== Лекция 5. Алгоритмы синхронизации
https://youtu.be/7aabRlVERPc

lock-free - гарантируется что ни один поток не будет заблокирован

wait-free - это lock-free + гарантируется за сколько шагов завершится

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

== Лекция 6. Ошибки || программирования
https://youtu.be/2A3Q0dA6Tlc
1) dead lock
- перекрестный лок ресурсов = захватывать ресурсы глобально на уровне приложения
- использование не рекурсивного примитива синхронизации в одном потоке
- форк может скопировать и примитив синхронизации и форк будет ждать вечно -> pthread_at_fork()

fork делает COW относительно родительского, ну мол нафига копировать все ? давай скопируем только то что меняет родитель или собирается менять

2) data race
в ФП они 99.999% невозможны

3) ABA' - подмена незаметная для других (буферизация, кэширование, аллокаторы)

4) потерянный сигнал (послали SIG но обработчик еще не поставили). надо выставлять SIG_MASK показывая явно что этот поток не реагирует на сигнал.

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

== Лекция 7. Атомарные снимки регистров
https://youtu.be/oq6krtEvCLA
обьяснение лайтовой версии алгоритма "MVCC" (который используется в любой нормальной БД)

== Лекция 8. Java.util.concurrent
https://youtu.be/zMj1Qi_N9Qc
джаве видней какой мутекс заюзать... либо быть супер оптимистичной и вставить тут Spin-Lock либо быть более прагматичной - и вставить обычный мутекс

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

ну и да... ей видней когда наесться памяти и заснуть )))))

== Лекция 9. OpenMP и Intel TBB
https://youtu.be/_MKbLk6K_Tk
обзор технологий
openMP
- удобные для вычислений прагмы, превращающие все в паралельный код

tbb:
- parallel algorythms
- tls
- mem allocators
- flow graphs
- ranges and partitioners
- tasks & task groups
- task schedulers
- concurrent containers
- sync primitives

BPEL
- XSD
- XML
- WSDL
- SOAP

https://vvsevolodovich.dev/profession-solution-architect-roadmap/
Profession: Solution Architect. Chapter 3: Architect Roadmap

оч хорошая лекция по профилированию многопоточного кода

== Лекция 10. Профилирование многопоточных приложений
https://youtu.be/d_3kCXSONWQ

утилита time
real - время наблюдаемое
user - процессорное время (в сумме по всем ядрам)
sys - кернел время (сумма по всем системным вызовам)
___
если real < user - используется ||
если real == user однопоток
если real >> user просадка, задержки, IO ожидания и тп

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

intel v-tune
может показать и дерево и время

в ОС есть механизм подгрузки библиотек раньше чем другие LD-PRELOAD

при многоядерной системе ОС применяет потоки на свободные ядра автоматом.

PMU
- inbstructions
- elapsed code clock ticks
- coder frequency
- l2 cache hints, misscaches
- data traffic
- read/write from memory controller

Java:
JMC

== Лекция 11. Проблема видимости переменных. Устройство процессора
https://youtu.be/VcesAbhnGKU

протокол когерентности процессора
каждое ядро имеет 2бита на каждую ячейку памяти для MESI в L кэше
- Exclusive (есть только тут)
- Invalidated
- Modified (полюбому должны быть синхронизированны с RAM, когда этот кэш будет вытесняться)
- Shared - когда несколько ядер могут иметь одно и тоже значение (ссылку)

когда останется только одно ядро которое владеет Shared ячейкой, то оно автоматом станет Exclusive

== Лекция 12. Барьеры памяти. Модели памяти
https://youtu.be/kg0ZVbBdsMM

MOESI - протокол со знанием владения (3бит)

барьеры памяти
smp-rmb
smp-wmb
smp-mb

бывают Store/Load

барьер load_load - гарантирует что все чтения до барьера будут выполнены до всех чтений после этого барьера
аналогично для store_load/store_store/load_store

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

volatile это спец слово для JAVA коорая подбирает специальные барьеры
а на C++ volatile это просто запрет на оптимизацию

store_load не тривиален

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

Модели памяти
- sequential consistency - любая операция чтения/записи применяет автоматом барьеры
- strong-ordered - (acquare/release семантика из коробки)
- weak-ordered - нужно руками всегда ставить - напрмиер в АРМ
- super-weak - (старая архитектура альфа) - могут быть изменен порядок иснтрукций координально и опасно

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

Memory Barriers: a Hardware View for Software Hackers

Paul E. McKenney
Linux Technology Center
IBM Beaverton
2010

== Лекция 13. Шаблоны || программирования. Консенсус
https://youtu.be/C_v800s4Axs

чем меньше шаред мемори - тем лучше

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

1) pipeline
2( double check

== Лекция 14. Транзакционная память
https://youtu.be/HgRGGKqeod8
i/o
- блокирующий = ждет заполнения буфера
- не блокирующий = если в буфере ничего нет на момент опроса - просто вернет что ничего нет

i/o
- синхронный - детерменированно ждет завершения опирации
- асинхронный - работа через событие

если можно сделать аналогию с сигналами - то асинхронно, если нет - это синхронный случай

>
callback -> eventQueue -> demultiplexor -> proactor -> callback

select это функция POSIX в которую передется набор дескрипторов (сокетов), а обратно получашь набор тех которые сработали

epoll использует eventQueue ОС

== Обзор архитектуры x86
https://youtu.be/POiuH3sue3M
модель памяти
- сегментация, ретрансляция адресов
виртуальная память это и есть страничная организация памяти

ассемблер
- все что начинается с точки - это не к процессору а к ассемблеру
- часть команд зависит от состояния регистров флагов
- command, soruce, dest
- операнды

== x86 Protected mode overview
https://youtu.be/BW6C6dFByKQ

- логический адрес (селектор, смещение)
- линейный адрес (таблица, страница, смещение)
- физический адрес (на шине памяти)

GDTR
IDTR

чтобы получить данные 2 шага:
каталог страниц -> поулчить страницу
страница -> получить данные по оффсету

регистры
cr0 - системные контрольные флаги
cr2 -
cr3 - физический адрес базы каталога страниц и 2 флага ( PageLevelCaceheDisable, PageLevelWritesTransparentL1L2)
cr4 - флаги SIMD

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

процессору нужен контроллер прерываний (в составе чипсета)

- немаскируемые прерывания
- маскируемые прерывания (каскадируемые многоуровневые)

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

при обработке прерывания проверяется уровень привелегий

== Создание первого процесса. Инициализация операционной системы
https://youtu.be/DFdNMXNoWn8

процесс
- обладает потоками
- работает до тех пор пока есть что исполнять
- НЕТ стэка (он есть у потока)

PID - Process ID
TGID - Thread Group ID

любой процесс создается (кроме Саааамого первого init процесса)
- через fork
- через exec
- через clone (куча флагов настройки)
- через unshare (может создавать свое пространство процессов, став аля init процессом)

fork полностью копирует родительский. передает PID родителю. НО адресное пространство другое.
регистры общего назначения не сохраняются (это гарантирует уже юзер код)

ответсвенный за уборку мусора после смерти процесса - родитель

Состояние:
- running
- ready (runnable)
- wait (ждет исполнения IO или другого от ОС)

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

switchuvm() переключает контексты. сохраняется текущий стэк

syscall
- fork
- exit
- wait
- pipe
- read
- kill
- exec
- fstat
- chdir
- dup
- getpid
- sbrk
- sleep
- uptime
- open
- write
- mknod
- unlink
- link
- mkdir
- close

How do debuggers (really) work?

== Как работает процессор
https://youtu.be/kIrKeKiJt90

RAM:
- шина адреса
- шина данных
- шина управления (установить/получить)

- Управляющее устройство
- АЛУ
- регистр
- шина процессора
- временный буфер
- регистр инструкций