Computer Science

LOLCODE — это уникальный язык программирования, основанный на интернет-меме "LOLcats". Программы на LOLCODE выглядят как текст на "языке" LOLcats. Пример простой программы на LOLCODE, которая выводит "Hello World!": HAI 1.2 CAN HAS STDIO? VISIBLE "HAI WORLD!" KTHXBYE HAI 1.2 — начало программы, указывающее версию языка. CAN HAS STDIO? — импорт стандартной библиотеки ввода-вывода. VISIBLE "HAI WORLD!" — вывод строки "HAI WORLD!" на экран. KTHXBYE — завершение программы.

Текст на "языке" LOLcats обычно выглядит как забавные и искаженные фразы, часто сопровождаемые изображениями кошек. I CAN HAS CHEEZBURGER? OH HAI! U CAN HAS CHEEZBURGER! Cтиль письма стал популярен благодаря интернет-мемам с изображениями кошек и смешными подписями.

Архитектура Клиент-Сервер: Технический разбор

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

Стек технологий и протоколы 1. Транспортный уровень: TCP/IP (гарантирует доставку пакетов). 2. Прикладной уровень: HTTP/HTTPS (правила обмена данными). 3. Форматы данных: JSON, XML, HTML, Protobuf. 4. Порты: 80 (HTTP), 443 (HTTPS), 22 (SSH), 3306 (MySQL) и др. Жизненный цикл запроса (Request-Response Cycle) • DNS Resolution: Клиент преобразует домен (example.com) в IP-адрес сервера через DNS-запрос. • TCP Handshake: Установление соединения (SYN → SYN-ACK → ACK). • HTTP Request: Клиент отправляет запрос. • Server Processing: Бэкенд обрабатывает логику, делает запросы к БД (SQL/NoSQL). • HTTP Response: Сервер возвращает статус и данные. • Rendering/Parsing: Клиент обрабатывает ответ (рендеринг HTML или парсинг JSON). • Connection Termination: Закрытие соединения (TCP FIN). Структура HTTP-запроса и ответа: Запрос (Client → Server): POST /api/login HTTP/1.1 Host: example.com Content-Type: application/json Authorization: Bearer <token> { "username": "user1", "password": "secure_pass" } • Method: GET, POST, PUT, DELETE. • Headers: Метаданные (cookies, auth, content-type). • Body: Полезная нагрузка (payload). Ответ (Server → Client): HTTP/1.1 200 OK Content-Type: application/json Set-Cookie: session_id=abc123 { "status": "success", "user_id": 456, "token": "eyJhbGci..." } • Status Code: Результат обработки (200, 404, 500). • Headers: Информация о сервере, кэшировании, куки. • Body: Данные или сообщение об ошибке. Коды состояния HTTP (Status Codes) • 2xx (Success): - 200 OK — запрос успешен. - 201 Created — ресурс создан. - 204 No Content — успешно, но без тела ответа. • 3xx (Redirection): - 301 Moved Permanently — постоянный редирект. - 302 Found — временный редирект. • 4xx (Client Error): - 400 Bad Request — ошибка в синтаксисе запроса. - 401 Unauthorized — нужна авторизация. - 403 Forbidden — доступ запрещен. - 404 Not Found — ресурс не найден. • 5xx (Server Error): - 500 Internal Server Error — ошибка на стороне сервера. - 502 Bad Gateway — шлюз получил неверный ответ. - 503 Service Unavailable — сервер перегружен.

📝 Курс от OTUS: «Администрирование PostgreSQL. Экспертный уровень» — продвинутое погружение в работу с базой данных PostgreSQL в любых средах. Освойте управление PostgreSQL на экспертном уровне: от настройки локальной инфраструктуры до развёртывания высокодоступных кластеров в облаках и Kubernetes. Научитесь автоматизировать процессы, оптимизировать производительность и экономить ресурсы — без лишних сервисов и избыточных затрат. 🔥 Приглашаем на серию из 2 бесплатных вебинаров курса — для DevOps‑инженеров, SRE, архитекторов данных, администраторов БД и разработчиков, которые хотят выйти на новый уровень владения PostgreSQL. 🔧💾 📅 26 марта в 20:00 МСК: «Путешествие запроса в PostgreSQL: от разбора до исполнения (от parser до executor)» На вебинаре разберём, как PostgreSQL превращает текст запроса в результат — вскроем «чёрный ящик» и изучим каждый этап: • От текста к дереву: как работают лексер и парсер, что такое parse tree и query tree, и зачем нужен rule rewriter (на примере того, как VIEW превращается в подзапрос). • Планировщик изнутри: как оптимизатор строит plan nodes, оценивает стоимость через статистику (pg_statistic, correlation, MCV) и почему иногда ошибается. • Executor и runtime: как plan tree исполняется итераторной моделью (Volcano model), где живут данные в памяти. • Как читать EXPLAIN ANALYZE, чтобы видеть реальные узкие места. Результат: вы поймёте, как именно PostgreSQL обрабатывает запросы, научитесь осознанно оптимизировать производительность — без метода подбора индексов. Уйдёте с чётким алгоритмом анализа и устранения «узких мест». 📅 9 апреля в 20:00 МСК: «PostgreSQL как векторная база данных: ИИ‑поиск без лишних сервисов» На вебинаре разберём, как использовать PostgreSQL с расширением pgvector для семантического поиска и RAG‑систем — без внедрения отдельной векторной БД. Программа: • Работа с pgvector: установка, типы данных, индексы. • Сравнение PostgreSQL и специализированных векторных БД по скорости и точности. • Проектирование гибридного поиска (точный + семантический) в рамках одной базы. • Выбор между индексами IVFFlat и HNSW для своей задачи. • Примеры RAG‑запросов с комбинацией tsvector и векторного поиска. • Успешные кейсы использования PostgreSQL для ИИ. Результат: вы сможете добавить ИИ‑функции в продукт без усложнения инфраструктуры. Уйдёте с готовым планом внедрения векторного поиска на базе PostgreSQL. 🎯 Почему стоит участвовать: - Получите практические инструменты: разбор реальных кейсов, шаблоны конфигураций, чек‑листы для аудита производительности. - Изучите современные решения: pg_probackup, Wal‑G, pg_rewind, pgvector. - Научитесь автоматизировать: используйте Terraform для установки ВМ и Ansible для развёртывания ПО. - Разберётесь в облаках: отличия GCP, Yandex Cloud, SberCloud, VKCloud и как эффективно работать в каждом. - Сможете задать вопросы практикующим инженерам и архитекторам PostgreSQL в прямом эфире. - Примените знания сразу после вебинаров: с готовыми скриптами и инструкциями. 👉 Регистрируйтесь сейчас, а мы напомним о вебинаре накануне. OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Краткие характеристики сетевых протоколов TCP (Transmission Control Protocol): • Обеспечивает надежную передачу данных через сетевые протоколы. • Устанавливает соединение (TCP handshake) перед передачей данных. • Гарантирует доставку данных в правильном порядке и без ошибок. • Используется для передачи данных в приложениях, требующих надежности, таких как веб-браузеры и клиенты электронной почты. UDP (User Datagram Protocol): • Протокол без соединения, не гарантирует доставку данных. • Быстрый и легкий протокол, используемый для передачи небольших пакетов данных. • Часто используется в приложениях, требующих быстрой передачи данных, таких как потоковая передача видео и аудио. HTTP (Hypertext Transfer Protocol): • Протокол передачи гипертекста, используемый для передачи данных между веб-сервером и веб-клиентом (браузером). • Работает поверх TCP и использует порт 80 по умолчанию. • Использует методы GET и POST для получения и отправки данных. HTTPS (HTTP Secure): • Защищенная версия HTTP, использующая протокол SSL/TLS для шифрования данных. • Используется для обеспечения безопасности передачи данных между веб-сервером и клиентом. • Работает поверх TCP и использует порт 443 по умолчанию. FTP (File Transfer Protocol): • Протокол передачи файлов, используемый для передачи файлов между клиентом и сервером. • Работает поверх TCP и использует порты 20 (для данных) и 21 (для управления) по умолчанию. • FTP не шифрует данные, поэтому для защиты конфиденциальных данных рекомендуется использовать FTP через SSL (FTPS) или SFTP. SMTP (Simple Mail Transfer Protocol): • Протокол простой передачи почты, используемый для передачи электронных писем между почтовыми серверами. • Работает поверх TCP и использует порт 25 по умолчанию. • SMTP не шифрует данные, поэтому для защиты конфиденциальных данных рекомендуется использовать STARTTLS или SMTPS. DNS (Domain Name System): • Протокол, используемый для преобразования доменных имен в IP-адреса. • Работает поверх UDP и использует порт 53 по умолчанию. • DNS является распределенной системой имен, состоящей из иерархически организованных серверов.

Механизмы блокировок в PostgreSQL. Бесплатный урок курса «PostgreSQL DBA» Блокировки в PostgreSQL редко выглядят как «ошибка». Обычно всё просто становится медленным: запросы зависают, транзакции живут слишком долго, а база начинает вести себя непредсказуемо. И пока вы не научитесь диагностировать блокировки и понимать, как они возникают, вы будете «тушить пожары» вместо управления системой. 📅 На открытом уроке 25 марта (ср) в 20:00: — Сделаем практический разбор механизмов блокировок в PostgreSQL: от базовых типов до диагностики проблем. — Разберём блокировки объектов, строк и блокировки в памяти и то, как они влияют на производительность. — Научимся находить конфликты и «узкие места» через системные представления, выявлять долгие транзакции и разбирать взаимоблокировки (deadlocks). — Отдельно — профилактика: как проектировать схему и транзакции так, чтобы снижать конфликты и повышать параллельную работу.

Урок не для тех, кто пишет «как получилось» и потом удивляется deadlock’ам, или хочет выучить одну команду и «закрыть тему блокировок навсегда».

👉 Записаться: https://otus.pw/9rba/ Реклама. ООО «Отус онлайн‑образование», ОГРН 1177746618576

npm = Node Package Manager Менеджер пакетов для Node.js. Основная цель: управлять библиотеками (пакетами) для JavaScript/Node-проектов. С его помощью можно: • Устанавливать готовые пакеты (npm install) • Создавать свои пакеты (npm init) • Обновлять пакеты (npm update) • Управлять зависимостями проекта через package.json Как работает npm: npm состоит из трёх ключевых компонентов: 1. Командная строка (npm CLI) • Ты вводишь команды: npm install express • CLI обрабатывает запрос и общается с реестром npm. 2. npm Registry (репозиторий пакетов) • Онлайн-хранилище всех пакетов: https://www.npmjs.com/ • Когда ты устанавливаешь пакет, CLI загружает его с этого репозитория. 3. node_modules и package.json • Установленные пакеты хранятся в папке node_modules. • Файл package.json фиксирует, какие пакеты и версии нужны для проекта. Принцип работы установки пакета: Пример: npm install lodash 1. CLI проверяет локальный кэш (~/.npm) — есть ли пакет уже скачан. 2. Если нет — скачивает пакет из npm Registry. 3. Устанавливает пакет в node_modules проекта. 4. Добавляет запись о пакете в package.json и package-lock.json. Разновидности установки: Локально: для конкретного проекта npm install lodash Глобально: доступно в системе для всех проектов npm install -g nodemon Основные файлы npm-проекта: 1. package.json — список зависимостей и скриптов проекта. 2. package-lock.json — фиксирует точные версии всех зависимостей для стабильности. 3. node_modules/ — физическое место хранения всех пакетов.

QR-код представляет собой двухмерный матричный штрих-код, состоящий из черных и белых квадратных модулей, размещенных на белом фоне. Он содержит информацию в виде набора байтов, которая может быть расшифрована специальным сканером или мобильным устройством. QR-код состоит из следующих элементов: Поисковая позиция (англ. Finder pattern) - три квадрата в углах QR-кода, служат для автоматической коррекции, поиска и выравнивания кода. Калибровочные полосы (англ. Alignment pattern) - несколько квадратов, расположенных на определенном расстоянии друг от друга внутри QR-кода, необходимы для расчета размеров и положения символов. Синхронизационные строки (англ. Timing pattern) - вертикальные и горизонтальные полосы, определяющие размер и форму кода. Данные - байты информации, которую необходимо закодировать в QR-коде, которые представлены в бинарном или текстовом формате. Информационные области - области, заполняемые модулями, отображающими данные. Коррекционные биты - блоки данных, используемые для коррекции ошибок, которые возникают при считывании QR-кода. QR-код может содержать различные типы информации, включая текст, URL-адреса, контактные данные, номера телефонов и прочее. Количество информации, которое может быть закодировано в QR-коде, зависит от его размера и уровня коррекции ошибок.

PostgreSQL и секционирование: «разделяй и властвуй!». Бесплатный урок курса «PostgreSQL для администраторов баз данных и разработчиков» Большие таблицы в PostgreSQL сначала «просто растут», а потом внезапно начинают убивать всё вокруг: запросы тормозят, вакуум длится вечность, обслуживание превращается в боль, а любой релиз страшно трогать. Секционирование — один из немногих инструментов, который реально помогает вернуть управляемость и скорость, если применять его правильно. 📅 На открытом уроке 16 марта (пн) в 20:00: — Разберём, зачем вообще нужно секционирование и какие проблемы больших таблиц оно решает. — Пройдёмся по основным видам секционирования в PostgreSQL: по списку значений, по диапазону и по хэшу. — Отдельно разберём декларативный подход, как современный способ секционирования: синтаксис, создание и обслуживание секций, добавление и удаление, а также сравнение со старым методом через наследование. — В конце — лучшие практики и частые ошибки, из-за которых секционирование «не взлетает».

Урок не для тех, кто ищет одну универсальную схему «на все случаи», хочет «ускорить всё одним движением» и не готов менять модель данных и запросы под реальную нагрузку.

👉 Записаться: https://otus.pw/9ydp/ Реклама. ООО «Отус онлайн‑образование», ОГРН 1177746618576

Магнитный принцип чтения информации Запись информации происходит на магнитно-чувствительный материал. Магнитное покрытие толщиной в несколько миллиметров нанесено на немагнитный каркас и имеет доменную структуру (состоит из множества микроскопических намагниченных частиц - доменов)  Магнитные поля доменов, попав под воздействие внешнего магнитного поля, ориентируются в соответствии с направлением магнитных силовых линий. Когда внешнее поле перестает воздействовать на магнитные поля доменов, на поверхности этих микроскопических частиц образуются зоны остаточной намагниченности, то есть сохраняется информация о подействовавшем на диск магнитном поле.  При чтении информации магнитные головки проходят над дорожками. При считывании намагниченные ранее участки направляют ЭДС в головке, проходящей над таким участком. Изменение направления ЭДС за определённое время характеризует двоичную единицу, неизменность – нуль. При этом, указанный промежуток времени изменения ЭДС называют битовым элементом.

Методы кодирования символов указывают на способы представления символов в компьютерных системах. Некоторые из наиболее распространенных: ASCII (American Standard Code for Information Interchange): Это стандартное кодирование символов для компьютеров, основанное на английском алфавите. Он представляет каждый символ одним байтом (8 битами) и может быть использован для представления 128 различных символов. Unicode: Это международный стандарт для кодирования символов. Unicode расширяет ASCII, чтобы включить символы различных языков и символы, которые не входят в английский алфавит. Unicode может быть представлен различными способами, такими как UTF-8, UTF-16 и UTF-32, которые используют разное количество байтов для кодирования символов. UTF-8 (Unicode Transformation Format 8-bit): Это переменная длина кодирование символов Unicode, которое использует от 1 до 4 байтов для представления символов в зависимости от их кодового значения. UTF-8 обычно используется в Интернете и в большинстве современных компьютерных систем, так как он эффективно представляет широкий набор символов и поддерживает обратную совместимость с ASCII. UTF-16: Это кодирование символов Unicode с использованием 16-битных блоков данных. Оно может быть использовано для представления всех символов Unicode, но требует больше памяти, чем UTF-8. ISO-8859: Это набор стандартных кодировок символов, разработанных Международной организацией по стандартизации. Каждая кодировка ISO-8859 предназначена для определенного набора символов, таких как ISO-8859-1 для латинского алфавита.

Кодирование графической и видеоинформации — процесс преобразования аналоговых или цифровых данных изображений и видео в специальный формат, который занимает меньше места, сохраняя при этом необходимое качество. Кодирование графической информации: JPEG (Joint Photographic Experts Group): • Стандарт для сжатия статических изображений. • Позволяет настроить уровень сжатия, что влияет на баланс между качеством и размером файла. • Часто используется для фотографий и изображений с непрерывными тональными переходами. PNG (Portable Network Graphics): • Формат без потерь, хорошо подходит для изображений с прозрачностью. • Предоставляет поддержку 24-битной палитры и альфа-канала. GIF (Graphics Interchange Format): • Широко используется для анимированных изображений. • Поддерживает до 256 цветов, что делает его менее подходящим для фотографий, но хорошим для простых изображений с ограниченной цветовой палитрой. Кодирование видеоинформации: H.264 (MPEG-4 Part 10 AVC): • Один из наиболее широко используемых стандартов видеокодирования. • Обеспечивает высокое качество при сравнительно низкой пропускной способности. H.265 (High Efficiency Video Coding - HEVC): • Преемник H.264, обеспечивает еще более эффективное сжатие видео без ущерба для качества. VP9: • Открытый стандарт, разработанный Google. • Предназначен для сжатия видео с высоким разрешением при более низкой пропускной способности. AV1: • Еще один открытый стандарт, разрабатываемый Alliance for Open Media. • Предназначен для достижения высокого качества при сжатии видео и конкурирует с H.265.

DLL файлы, и для чего они нужны? Аббревиатура DLL – обозначает «Динамически Подключаемую Библиотеку». Она установлена, во всех операционных системах Windows, и практически каждая программа или игра на компьютере пользуется данной библиотекой. В ней содержится информация о конфигурации системы, совместимости устройств, наборе команд для правильной работы и многое другое.  DLL файлы – это компоненты библиотеки, а нужна она для запуска программ, приложений и игр. Компьютер включился, и система работает исправно. Вы еще ничего не запускали и не открывали, а уже десятки DLL файлов используются. Простые часы, информация о конфигурации системы, порядок запуска программ, оформление и многое другое используют библиотеку. Для того чтобы в текстовом документе начали появляться символы, соответствующие вашему вводу, нужна библиотека. По умолчанию система не знает, что означает нажатая вами клавиша,─ в этом его помогают компоненты DLL. Аналогичная ситуация со всеми подключаемыми устройствами: принтером, мышью, клавиатурой, флеш-картой. Именно библиотека DLL файлов «рассказывает» им, как работать с параметрами вашей системы.

Злоумышленники усложняют фишинг, объем утечек растет Фишинг стал сложнее, а утечки данных — масштабнее. Готова ли ваша ИБ-команда к новым вызовам? 3 марта эксперты «Солара» проведут ежегодный вебинар «Тренды информационной безопасности 2026: аналитика, кейсы, прогнозы от Solar JSOC». Покажем аналитику и разберем: - Как изменился ландшафт киберугроз в 2025 году для разных отраслей и чего ждать в 2026. - Какие внешние угрозы стали ключевыми и как им противостоять. - Как TI-фиды повышают эффективность SOC — рассмотрим реальные кейсы. Регистрируйтесь и получите инсайты для комплексной защиты бизнеса. Зарегистрироваться #реклама 16+ rt-solar.ru О рекламодателе

Инструменты для управления политиками безопасности Эти инструменты помогают контролировать соблюдение политик безопасности в процессе разработки и эксплуатации. • OPA (Open Policy Agent): Открытый агент для управления политиками, который можно интегрировать в разные этапы DevOps-пайплайнов. • Kubernetes RBAC: Управление доступом на основе ролей (Role-Based Access Control) в Kubernetes для контроля безопасности. Эти инструменты ([1], [2], [3], [4], [5], [6], [7], [8], [9]), в сочетании с процессами DevOps и практиками безопасности, помогают создавать безопасные и надежные программные решения, снижая риски и улучшая общую безопасность на всех этапах разработки и эксплуатации.

Таблица разделов Таблица разделов — часть главной загрузочной записи (MBR), состоящая из четырёх записей по 16 байт. Каждая запись описывает один из разделов жёсткого диска. Первая запись находится по смещению 1BEh от начала сектора, содержащего MBR, каждая последующая запись вплотную примыкает к предыдущей. Для создания на диске более 4 разделов используются расширенные разделы, позволяющие создать неограниченное количество логических дисков внутри себя. Адреса начала и конца раздела задаются в формате CHS, используемом традиционными функциями дискового сервиса BIOS, из-за чего номер цилиндра разорван на две части: старшие два бита хранятся в двух старших битах слова, отведённого под номера цилиндра и сектора; за ними следуют шесть бит номера сектора, а младшие восемь бит номера цилиндра занимают весь младший байт слова. Если задать корректный адрес с помощью формата CHS невозможно, все три байта полей начала и конца раздела должны содержать FFh

Хеширование, коллизии и деградация Хеш-таблицы зависят от: • качества хеш-функции • стратегии разрешения коллизий • коэффициента заполнения Открытая адресация страдает от кластеризации, цепочки — от неравномерного распределения. Пример: При нагрузке > 0.75 среднее число проб резко растёт. Рехеширование — операция O(n) и может стать латентным пиком в продакшене, если не контролировать рост. Реальность: O(1) — это статистическое обещание, а не гарантия.

Стоимость операций: CPU, кэш и память Асимптотическая сложность не отражает реальную стоимость операций. Современный процессор выполняет инструкции за наносекунды, но доступ к: • L1 кэшу — ~1–4 такта • L3 — десятки тактов • RAM — сотни тактов Алгоритмы с линейным проходом по памяти часто выигрывают у «умных» алгоритмов со случайным доступом. Пример: Поиск минимума в массиве — O(n) — почти всегда быстрее бинарного поиска в несмежных структурах, несмотря на худшую формальную сложность. Причина — предвыборка и кэш-линейность.

Теория формальных языков изучает структуры и свойства языков, описанных формальными системами. Основные аспекты: 1, Грамматики: Формальные правила, которые определяют синтаксис языка. Основные типы: - Контекстно-свободные грамматики (КС-грамматики): Определяют синтаксис языков, которые можно описать с помощью синтаксических деревьев (например, язык программирования C). - Контекстно-зависимые грамматики: Более мощные и сложные, позволяют описывать языки с контекстуальными зависимостями (например, естественные языки). 2. Автоматы: Математические модели для описания и распознавания языков. - Конечные автоматы: Описание языков с помощью простых состояний и переходов (например, регулярные языки). - Стековые автоматы: Модели с использованием стека, применимые к контекстно-свободным языкам. 3. Языки: - Регулярные языки: Определяются регулярными выражениями и распознаются конечными автоматами. - Контекстно-свободные языки: Определяются контекстно-свободными грамматиками и распознаются стековыми автоматами. - Контекстно-зависимые языки: Определяются контекстно-зависимыми грамматиками и распознаются более мощными машинами. 4. Классы языков: Иерархия языков в зависимости от сложности грамматик и автоматов, таких как регулярные, контекстно-свободные, контекстно-зависимые и рекурсивно перечисляемые языки. 5. Операции над языками: Способы объединения, пересечения, дополнения и другие операции для работы с языками.

Обработка артефактов сканирований. Сканирование запустили — а что дальше Запустить security-сканер — лишь половина дела. Гораздо сложнее превратить результаты сканирования в рабочий процесс, который действительно приводит к исправлению уязвимостей, а не к накоплению отчётов «на складе». На открытом уроке разберём, как выстраивать работу с артефактами сканирований в GitLab CI/CD. Поговорим о хранении результатов, передаче их разработчикам и настройке security gates, которые автоматически влияют на сборку и релиз. Обсудим, как встроить безопасность в пайплайн так, чтобы она работала системно и не превращалась в формальность. Урок будет полезен DevSecOps и AppSec-специалистам, DevOps/SRE-инженерам и тимлидам, которые хотят наладить управляемый поток обработки результатов security-сканирований. → Вебинар проходит в формате открытого урока курса «Внедрение и работа в DevSecOps»: https://otus.pw/aZCg/ Реклама. ООО «Отус онлайн‑образование», ОГРН 1177746618576

Формальная верификация уже спасает миллиарды Amazon доказал корректность частей S3 и DynamoDB с помощью TLA+. Microsoft верифицирует гипервизор в Dafny. Простейший пример в PlusCal (транслируется в TLA+):

(*--algorithm mutex
variables flag = [i \in {1,2} |-> FALSE];

process proc \in {1,2}
begin
  A: flag[self] := TRUE;
  B: await flag[3-self] = FALSE;
  C: skip;  (* critical section *)
  D: flag[self] := FALSE;
  E: goto A;
end process;
end algorithm;*)

Этот алгоритм НЕ корректный (возможен deadlock). TLC (model checker) найдёт ошибку за секунды. Начать легко: установите Toolbox, попробуйте на простых примерах mutual exclusion.