Параллельное программирование *

Время от времени я вольно или невольно возвращаюсь к теме RS-триггера. Время проходит, а «народ», как не понимал его, так и не понимает. Таблица истинности (ТИ), запрещенные состояния упорно всплывают, как непотопляемый Ванька-встанька. Но сколько раз твердили миру, что ТИ – это про истинно комбинационные схемы, а RS-триггер - посконно последовательностная схема (последовательностная – это не ошибка). А запрещенные состояния? Кто, где и каким указом запретил их?  Так он и послушался?! Все в сумме - верх безграмотности! Чем бы это не оправдывалось. Например, желанием упростить описание.

И пусть, сцепив зубы - упростили, зажав совесть в кулак – запретили и, наступив на гордость, пошли на поводу. Однако, казалось бы, можно, сохранив реноме, намеком, эзоповым языком сказать, что картина-то другая.  Но совесть и гордость не страдают, а Эзоп просто отдыхает, т.к. почти невозможно отыскать источники, где истина о триггере открывается без прикрас и упрощений.  А потому те, кто глаголет о триггере, похоже, как его представляют, так о нем и пишут. Их совесть, и гордость ни что не беспокоит. Но, как быть с реноме?

Может, я что-то не понимаю? Конечно, не в RS-триггере.  С ним мне давно все ясно, как и понятна его роль в нынешнее бурное время становления параллелизма.

Но беда в том, что искусственный интеллект в лице того же DeepSeek «гонит» о триггере все ту же чушь. Его несложно, правда, убедить  в обратном. Конечно, обосновывая, конечно, доказывая. И надо отдать ему должное  он все схватывает буквально на лету, а  о чем-то, что тоже поражает, даже догадывается. Это обнадеживает. Не зря ли только?   

Однако, ИИ быстро забывает, чему его учишь. А это уже другая беда. Возможно, не такая уж большая, т.к. учить – не проблема. При этом, у человечества есть все, чтобы поставить точку в понимании RS-триггера, а заодно и параллелизма и, исправив учебники, научить этому и ИИ. Но оно почему-то эту точку не ставит? Что мешает?

А что вы думаете о RS-триггере? И в целом о ситуации?      

Сегодня я хочу выложить в открытый доступ свою библиотеку на Scala. Библиотека реализует Directed Acyclic Graph (DAG) для выполнения задач внутри одного приложения (на замену Airflow и подобных не претендую :-)) и позволяет определять задачи с зависимостями, выполнять их в правильном порядке и обрабатывать исключения, которые могут возникнуть в процессе выполнения. Библиотека писалась через призму моих личных и профессиональных потребностей, поэтому не претендует на покрытие всех возможных кейсов, встречающихся в разработке вообще.

Use case_:

Иногда возникает необходимость выполнять взаимосвязанные задачи/функции/классы в рамках одного приложения, где эти задачи могут быть частично параллелизованы, то есть их можно "собрать" в DAG для более эффективного использования ресурсов и повышения общей производительности. Например при обрабтке/загрузке данных или в event-driven приложении.

Особенности_:

• Управление задачами: Добавление задач с указанными зависимостями.

• Гибкость: Выполенение всех или только некоторых задач (с сохранением зависимостей)

• Обработка ошибок: Встроенная обработка ошибок с передачей исключений "наверх" для упрощенного их анализа.

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

Код, документация и инструкция по импорту и использованию доступны на GitHub.

Буду рад любым отзывам и предложениям по улучшению. Также не стесняйтесь задавать вопросы и заводить issue :-)

Модификация UI элементов не в основном потоке Unity

В настоящее время я активно изучаю и использую Unity для разработки проекта с AR и столкнулся с классической проблемой "модификации UI элементов не в основном потоке" - так делать нельзя, поскольку средой будет вызвано исключение UnityException.

В рамках изучения этого вопроса я далеко не сразу нашёл решение. Передо мной стояла задача сделать обработку сообщения, получаемого по каналу связи через WebSocket, изменив при этом некоторые UI элементы. Обработка происходит не в основном потоке.

Через некоторое время я наткнулся на одно из возможных решений этой проблемы через очередь задач, которая решает данную проблему:

// Экземпляр WebSocket
private WebSocket _ws;

// Очередь команд для обработки
private readonly ConcurrentQueue<Action> _actions = new ConcurrentQueue<Action>();

void Start()
{
    // ...
    ConnectWebSocket();
}

void ConnectWebSocket()
{
    // ...
  
    // Добавление обработчика ответа от сервера
    _ws.OnMessage += OnMessage;
  
    // ...
}

void Update()
{
  // ...
  while (_actions.Count > 0)
  {
    if (_actions.TryDequeue(out var action))
    {
      // Выполнение задачи из очереди
      action?.Invoke();
    }
  }
}

void OnMessage(object sender, MessageEventArgs e)
{
  // Добавление команды в очередь
  _actions.Enqueue(() => MessageHandler(sender, e));
}

void MessageHandler(object sender, MessageEventArgs e)
{
  // Данный блок кода выполняется в основном (main) потоке
}