CODESYS V3.5. Вопросы и ответы

[Cs-Cs]

> Какую практическую задачу из вашей предметной области вы пытаетесь сейчас решить?
Запись в один файл из нескольких потоков. Журнал действий пользователей, и системы.

А если сделать какой-то один объект (FB) с методом AddToLog()?
Пусть внутри FB файл всегда будет открыт, а AddToLog туда будет писать?

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

[fatlortroll]

Если чтение I/O сложить в один поток с логикой, получатся неприличные задержки.

А, там ещё вместе с I/O ещё обмен данными с шестью частотниками.

[fatlortroll]

> А если сделать какой-то один объект (FB) с методом AddToLog()

Так и сделано, но, похоже, там конкуренция среди них. И я криво реализовал синхронизацию.

[Cs-Cs]

> А если сделать какой-то один объект (FB) с методом AddToLog()
Так и сделано, но, похоже, там конкуренция среди них. И я криво реализовал синхронизацию.

А что ты называешь потоками? Разные задачи?

А если сделать очередь? =) Типа при вызове AddToLog всё пишется в очередь (массив структур с данными), а потом он спокойно скидывается на диск. В одном, своём потоке (задаче)

[Евгений Кислов]

Шаман, как обычно, смотрит в корень - то, что события могут формироваться в разных потоках, не мешает обрабатывать их в каком-то одном потоке.

Если чтение I/O сложить в один поток с логикой, получатся неприличные задержки.

Использование SysFile и других библиотек с синхронными вызовами - действительно довольно простой способ получить "неприличные задержки".
Для большинства библиотек есть асинхронные варианты - например, в случае файлов это библиотека CAA File.

[fatlortroll]

> А что ты называешь потоками? Разные задачи?

Ага.

> А если сделать очередь?

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

[fatlortroll]

> обрабатывать их в каком-то одном потоке

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

[Евгений Кислов]

> обрабатывать их в каком-то одном потоке

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

Если это один поток и всё же SysFile - о какой вообще синхронизации речь?
Вызовы SysFileOpen, SysFileWrite и т.д. - блокирующие.

[fatlortroll]

Возможно, я некорректно представляю модель исполнения CoDeSys, но разве при вызове метода ФБ из разных потоков (задач) не может случиться коллизия, даже если функции внутри этого метода блокирующие?

[Евгений Кислов]

Возможно, я некорректно представляю модель исполнения CoDeSys, но разве при вызове метода ФБ из разных потоков (задач) не может случиться коллизия, даже если функции внутри этого метода блокирующие?

А зачем вообще об этом думать?

Пример реализации, совпадающий с озвученной выше Шаманом идеей ("простое лучше сложного"):
- глобальный ARRAY [FIRST_EVENT...LAST_EVENT] OF BOOL
- из разных потоков по событиям взводим нужные флаги массива (доступ к массиву по константным индексам - можно через красивый ENUM - все события заранее известны и определены)
- в одном конкретном потоке: открываем файл, в цикле проходим по массиву - для каждого установленного флага вызываем SysFileWrite (и здесь же можно реализовать форматирование сообщения, если требуется) и сбрасываем флаг - после выхода из цикла закрываем файл