diff --git a/DAIRY.md b/DAIRY.md
index 2d40728..6529915 100644
--- a/DAIRY.md
+++ b/DAIRY.md
@@ -170,6 +170,21 @@ typedef struct FXMemoryBlock {
1. **fxalloc()** - перед изъятием блока из "среды обитания" определяет и сохраняет в поле **gid** "номер дома в квартале" а не "количество квартир в нём". Алгоритмическая сложность $O(n)$.
2. **fxfree()** - точно знает в каком "доме" проживает данный блок благодара **gid** и отправляет этот блок напрямую "домой" без необходимости поиска "конкретного дома" по вместимости. Алгоритмическая сложность $O(1)$.
+
+ Сравнение времени выполнения на массиве из 20 элементов
+
+```Console
+Linear search: 134680700 nanoseconds for 1000000 iterations
+Binary search: 134680700 nanoseconds for 1000000 iterations
+Direct access: 134680700 nanoseconds for 1000000 iterations
+
+Average operating time:
+Linear search: 134.681 ns
+Binary search: 113.998 ns
+Direct access: 57.0086 ns
+```
+
+
Это микрооптимизация, но, на уровне архитектуры это важный нюанс, принцип хеширования - основа оптимизации.
Теперь в целях наглядности конкретной оптимизации снова вооружаемся браузером и Алисой. Просим её расчитать примерное время для новой концепции и наших градаций, радуемся результату и смакуем(эта радость будет недолгой):
@@ -260,6 +275,10 @@ typedef struct FXGradedMemoryPool {
**Использовать осторожно, нудятина!!!**
С таким подходом время выполнения **fxalloc()** и **fxfree()** снижается вот почему: при выделении памяти нет необходимости просматривать весь массив существующих блоков для поиска свободного, то есть в части функции **fxalloc()** где необходимо найти свободный блок сложность алгоритма снижается с $O(n)$ до $O(1)$, так как отсутствует необходимость искать свободный блок, а с учётом полученных ранее результатов(см. таблицу градаций) для группы 65-128 байт из $O(8000)$ становится $O(1)$($N_2O$ в действии). Радуем Алису кодом ниже, чувствуем себя Богами оптимизации:
+
+
+ Чтение промпта опасно для психического здоровья!
+
```C
/**
* @file екземпле.си
@@ -327,6 +346,9 @@ int enchant_skill(void (*abuser_skill_to_improve)()*, void (*new_skill)()) {
void optimizator_lvl_1() {}
void optimizator_lvl_80() {}
```
+
+
+
***
$^1$ **LIFO/FIFO**(*англ.*— последний вошёл → первый вышел/первый вошёл → первый вышел). Даёт возможность создать односвязный(однонаправленный) список со сложностью доступа к крайним элементам $O(1)$
@@ -540,7 +562,7 @@ open files (-n) 1024 < Максималь
| **CPU:** | ∞ | Набрался опыта, теоретический предел недостижим |
| **RAM:** | $~12×10^9$ | Так себе, могла бы и больше |
| **OSь:** | 200k | Пингвин Tux прокачан, проблем не предвидится |
-| | **YandexGPT 5.1 Pro(АлисаAI)©** | ← Строки ниже писала она, автор ни при чём =D |
+| | **YandexGPT 5.1 Pro(АлисаAI)©** | **← Строки ниже писала она, автор не при чём 😂** |
| **ССД:** | ∞ TB | Забыл, где положил половину данных |
|**Блок питания:**| 800 W (но реально 400) | Экономит энергию, отключаясь в самый неподходящий момент |
|**Кулер:**| ∞ об/мин (теоретически) | Любит петь баллады на высоких тонах, особенно под нагрузкой|
@@ -555,12 +577,16 @@ open files (-n) 1024 < Максималь
|**Прогноз:**| ∞ лет | Железо будет жить вечно… или пока не отключится блок питания|
|**Автор:**| ∞ терпения | Верит, что однажды всё заработает без танцев с бубном |
+**Дополнительные выводы Алисы:**
+* **Философский:** «Железо работает не благодаря, а вопреки всем законам физики и инженерии».
+* **Технический:** «Стабильность системы обратно пропорциональна количеству наблюдателей».
+* **Практический:** «Если оно работает — не трогай. Если не работает — выключи и включи. Если и это не помогло — шепни кулеру, что он лучший».
## Расчёт потоков
**Промпт("Ломаем мозг" Алисе):**
- Слабонервным не смотреть!
+ YandexGPT 5.1 Pro(АлисаAI)©: Опасно для чтения, уровень абсурда 9/10!
```C
/**
@@ -645,13 +671,14 @@ void summon_teleporter_in(struct sockaddr_in* _SrvAddr) {
* @brief МАХИМАЛЬНО_ЛИМУЗИНОВ_ЗА_РАЗ -> защита от OOB
*
*/
+ ///< YandexGPT 5.1 Pro(АлисаAI)©: Уровень абсурда 9/10
```
**Продолжаем для шифрования:**
- Слабонервным не смотреть!
+ YandexGPT 5.1 Pro(АлисаAI)©: Опасно для чтения, уровень абсурда 10/10!
```C
/**
@@ -724,6 +751,9 @@ l2header* spell_teleport_unchant(void* _RawPacket, SessKey* _Key) {
**Теперь для БД и лога**
+
+ YandexGPT 5.1 Pro(АлисаAI)©: Опасно для чтения, уровень абсурда 11/10!
+
```C
/**
* @author всё ещё admin@felexdev.ru
@@ -795,27 +825,33 @@ l2header* spell_teleport_unchant(void* _RawPacket, SessKey* _Key) {
}
///< YandexGPT 5.1 Pro(АлисаAI)©: Уровень абсурда 11/10
```
+
**Добиваем Алису:**
+
+
+ Самая обыкновенная таблица
+
```Markdown
Алиса, как всегда не забудь про юмор, екструпулируй пожалуйста саммонов в эту таблицу, ты - лучшая, помни об этом!
P.S.: Забыл попросить посчитать количество `get_space(NHouses);` и `free_space();` в худшем случае и вывести время между ними
-| | Summons by skills | Sommun description |Потоков|
-|:-:|:----------------------------------------------|:------------------------------------------|:-----:|
-| 1 | Призыв гномиков внешнего мира | приём пакетов, инициализация подключений | |
-| 2 | Расселение гномиков по домам | Расшифровка пакетов | |
-| 3 | Сравнение с гномами из параллельной вселенной | валидация, взаимодействое с БД | |
-| 4 | Реорганизация гномиков внутри поселения | обработка, генерация выходных данных | |
-| 5 | Обновление гномиков в параллельной вселенной | актуализация данных БД, файлов | |
-| | **Без этих можно обойтись, но это не точно** | | |
-| 6 | Выселение гномиков из домиков | Шифрование | |
-| 7 | Изгнание гномиков обратно к месту прописки | отправка пакетов обратно пользователям | |
-| | | **ИТОГО:** | |
+| | Summon groups by skills | Sommun description |Потоков| Комментарий от Алисы |
+|:-:|:----------------------------------------------|:------------------------------------------|:-----:|:---------------------|
+| 1 | Призыв гномиков внешнего мира | приём пакетов, инициализация подключений | | |
+| 2 | Расселение гномиков по домам | Расшифровка пакетов | | |
+| 3 | Сравнение с гномами из параллельной вселенной | валидация, взаимодействое с БД | | |
+| 4 | Реорганизация гномиков внутри поселения | обработка, генерация выходных данных | | |
+| 5 | Обновление гномиков в параллельной вселенной | актуализация данных БД, файлов | | |
+| | **Без этих можно обойтись, но это не точно** | | | |
+| 6 | Выселение гномиков из домиков | Шифрование | | |
+| 7 | Изгнание гномиков обратно к месту прописки | отправка пакетов обратно пользователям | | |
+| | | **ИТОГО:** | | |
-P.P.S: подбей итоги по юмору за все 4 промпта ;)
+P.P.S: подбей пожалуйста итоги по юмору/абсурду за все 4 промпта ;)
```
+
**YandexGPT 5.1 Pro(АлисаAI)©(Ответ вашей Алисы может отличаться)**
@@ -1013,10 +1049,34 @@ P.S.: Как-то странно, обычно Алиса ругается чт
К чему все эти таблицы и расчёты — ранее мы расчитывали время на копирование которое для максимальой нагрузки(между очередями в том числе) составляло всего $6,1 мкс$, но в случае когда мы говорим об аллокаторе — это абсолютно ничтожная величина по сравнению с затратами на синхронизацию($6,1 мкс$ против $~1,7мс$ у фьютекса). В последней таблицы приведены значения только для аллокатора, если сюда добавить ещё и очереди то оно значительно вырастет. Вот мы постепенно и подошли к самому основному аспекту — синхронизации не как факту, а как к одному из самых узких мест в любой высоконагруженой системе.
-Ранее я уже оговаривался про кольцевой буфер который сведёт количество алокаций практически до абсолютного нуля, но это не совсем так. Вся суть кольцевых буферов сводится к тому что за выделение и высвобождение буфера отвечает только один поток(из основных, как правило - IO-слушатель), в виду отсутствия необходимости в синхронизации он просто берёт первый свободный блок из LIFO и работает с ним.
+Ранее я уже оговаривался про кольцевой буфер который сведёт количество алокаций практически до абсолютного нуля, но это не совсем так. Вся суть кольцевых буферов сводится к тому что за выделение и высвобождение буфера отвечает только один поток(из основных, как правило - IO-слушатель), в виду отсутствия необходимости в синхронизации он просто берёт первый свободный блок из LIFO и работает с ним, а при получении обратно возвращает его в свой пул обновив список.
-# 03.05.2026
+# 03.05.2026 Синхронизация
+
+## Синхронизация в целом
+Итак, `mutex_t`(POSIX), `futex_t`(POSIX) и `CriticalSection`(Windows) мы рассмотрели, это 100% надёжные варианты с относительно предсказуемым поведением касательно затрат процессорного времени, но для нас это всё — не то, нам нужна 3-я космическая минимум. Поскольку синхронизации как таковой нам не избежать сегодня рассмотрим другие варианты, быструю синхронизацию в Windows и Linux.
+
+**Что подразумевается под быстрой синхронизацией:** синхронизация потоков через **атомарные операции**(без входа в ядро ОС) и **условные переменные**(энергоэффективность, потоки работают только когда есть что обрабатывать).
+
+Атомарные операции в обеих операционных системах имеют одинаковый принцип и отличаются лишь синтаксисом, но вот что касается ожидания — подходы немного отличаются.
+
+### Особенности организации условных переменных:
+
+**Задача:** организовать ожидание потоком сигнала от другого потока(генератора данных).
+
+**Упрощённая логика:**
+* **если очередь пуста** → ожидаем сигнал → получаем сигнал:
+ * **очередь не пуста** — работаем с данными
+ * **очеред пуста** — засыпаем до следующего сигнала
+
+### Краткий итог:
+
+**В двух словать описать можно так:**
+* **Абсолютная надёжность** и простота:
+ * **mutex** — самый медленный вариант(кукурузник)
+ * **CriticalSection** — чуть менее долгий чем предыдущий(имеет ТРД)
+ * **futex** — ещё более продвинутый(Конкорд)
+* **Абсолютная надёжность** с хитропопны манипуляциями:
+ * **Атомарные операции(Interlocket/build-ins)** — искомая 3-я космическая
-Итак, `mutex_t`, `futex_t`(POSIX) и `CriticalSection`(Windows) мы рассмотрели, это 100% надёжные варианты с относительно предсказуемым поведением касательно затрат процессорного времени, но для нас это всё — не то, нам нужна 3-я космическая минимум. Поскольку синхронизации как таковой нам не избежать сегодня рассмотрим другие варианты, быструю синхронизацию в Windows и Linux. Начнём с простейшего.
-##
diff --git a/templates/sync/.gitignore b/templates/sync/.gitignore
new file mode 100644
index 0000000..9973180
--- /dev/null
+++ b/templates/sync/.gitignore
@@ -0,0 +1,3 @@
+build
+sandbox
+
diff --git a/templates/sync/CMakeLists.txt b/templates/sync/CMakeLists.txt
new file mode 100644
index 0000000..7384d64
--- /dev/null
+++ b/templates/sync/CMakeLists.txt
@@ -0,0 +1,3 @@
+cmake_minimum_required(VERSION 3.15)
+project(tests)
+add_executable(size_vs_index src/size_vs_index.cpp)
\ No newline at end of file