Всем привет.

В настоящий момент несколько независимых процессов могут писать данные в один и тот же файл.
Они открывают мьютекс, открывают файл, записывают данные, закрывают файл, освобождают мьютекс.

Это становится узким местом и требует оптимизации.
Велосипед: служба (вначале In Memory, затем отдельный процесс), с очередью для каждого файла. Отдельный поток на каждый файл, который разбирает данные и пишет пачками в файл.

Вопрос №1: возможно, это можно организовать без велосипеда? Стандартными средствами WinAPI?
Вопрос №2: можно ли избавиться от мьютекса, автоматически поставив в очередь всех желающих открыть файл на запись?

Здравствуйте, LWhisper, Вы писали:

LW>Всем привет.

LW>В настоящий момент несколько независимых процессов могут писать данные в один и тот же файл.
LW>Они открывают мьютекс, открывают файл, записывают данные, закрывают файл, освобождают мьютекс.

LW>Это становится узким местом и требует оптимизации.

Можно начать с того, чтобы держать файл открытым. Возможно этого окажется достаточно.

LW>Велосипед: служба (вначале In Memory, затем отдельный процесс), с очередью для каждого файла. Отдельный поток на каждый файл, который разбирает данные и пишет пачками в файл.

LW>Вопрос №1: возможно, это можно организовать без велосипеда? Стандартными средствами WinAPI?
LW>Вопрос №2: можно ли избавиться от мьютекса, автоматически поставив в очередь всех желающих открыть файл на запись?

Процессы пишут в одно и то же место в файле или в разные? Если в разные, можно блокировать не файл целиком, а конкретные места (LockFileEx), и таким образом увеличить конкурентность.

Второй важный вопрос, нужна ли процессу гарантия успешной записи для продолжения работы? Если да, то все эти танцы с отдельной службой мало помогут.

LW>Вопрос №1: возможно, это можно организовать без велосипеда? Стандартными средствами WinAPI?
LW>Вопрос №2: можно ли избавиться от мьютекса, автоматически поставив в очередь всех желающих открыть файл на запись?

атомарное добавление строки из множества процессов — было предложено очень интересное решение, но с использованием нативного API из ntdll

Здравствуйте, LWhisper, Вы писали:

LW>Всем привет.

LW>В настоящий момент несколько независимых процессов могут писать данные в один и тот же файл.
LW>Они открывают мьютекс, открывают файл, записывают данные, закрывают файл, освобождают мьютекс.

LW>Это становится узким местом и требует оптимизации.
LW>Велосипед: служба (вначале In Memory, затем отдельный процесс), с очередью для каждого файла. Отдельный поток на каждый файл, который разбирает данные и пишет пачками в файл.

LW>Вопрос №1: возможно, это можно организовать без велосипеда? Стандартными средствами WinAPI?
LW>Вопрос №2: можно ли избавиться от мьютекса, автоматически поставив в очередь всех желающих открыть файл на запись?

Я примерно такую штуку делал при помощи очереди (очередей) сообщений. Это была задачка с условием использования либо разделяемой памяти, либо очереди сообщений. я создал велосипедище. была одна очередь сообщений, куда новые процессы посылали сообщения о добавлении/удалении себя и при добавлении присылали id. Дла каждого добавляемого процесса создавалась своя очередь сообщений с именем [постоянная_составляющая]id. И уже в эти очереди записывались сообщения с данными. Очереди обрабатывались менеджером и как ни страшно это все может выглядеть, в конце получилось довольно удобно для использования. В оправдание подхода можно сказать, что это паттерн Manager/Worker или вроде того А очереди сообщений использовать бустовые одно удовольствие.

ЗЫ: не пинайте сильно

W>Можно начать с того, чтобы держать файл открытым. Возможно этого окажется достаточно.

Нельзя так "с правом на удаление". Если файл держать открытым, он будет помечен на удаление и все записи после оного пропадут. Удаление должно происходить быстро, на месте старого файла — создаваться новый.

W>Процессы пишут в одно и то же место в файле или в разные? Если в разные, можно блокировать не файл целиком, а конкретные места (LockFileEx), и таким образом увеличить конкурентность.

В конец файла.

W>Второй важный вопрос, нужна ли процессу гарантия успешной записи для продолжения работы? Если да, то все эти танцы с отдельной службой мало помогут.

Не нужна.

Здравствуйте, plastictown, Вы писали:

P>Я примерно такую штуку делал при помощи очереди (очередей) сообщений. Это была задачка с условием использования либо разделяемой памяти, либо очереди сообщений. я создал велосипедище. была одна очередь сообщений, куда новые процессы посылали сообщения о добавлении/удалении себя и при добавлении присылали id. Дла каждого добавляемого процесса создавалась своя очередь сообщений с именем [постоянная_составляющая]id. И уже в эти очереди записывались сообщения с данными. Очереди обрабатывались менеджером и как ни страшно это все может выглядеть, в конце получилось довольно удобно для использования. В оправдание подхода можно сказать, что это паттерн Manager/Worker или вроде того А очереди сообщений использовать бустовые одно удовольствие.

Да, именно к такому велосипеду всё и идёт.

Здравствуйте, EreTIk, Вы писали:

ETI>атомарное добавление строки из множества процессов — было предложено очень интересное решение, но с использованием нативного API из ntdll

Ага, благодарю, с вопросом мьютекса, можно сказать, разобрались.

Здравствуйте, LWhisper, Вы писали:

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

Здравствуйте, wildwind, Вы писали:

W>Ах, так это логи. Логи в нормальных приложениях каждый процесс пишет в свой файл. Шаринг лог-файлов между процессами чреват гораздо более серьезными проблемами, чем низкая производительность. А для управления и удобного просмотра логов есть множество инструментов.

Но мы живём в реальном мире.

Здравствуйте, LWhisper, Вы писали:

W>>Ах, так это логи. Логи в нормальных приложениях каждый процесс пишет в свой файл. Шаринг лог-файлов между процессами чреват гораздо более серьезными проблемами, чем низкая производительность. А для управления и удобного просмотра логов есть множество инструментов.

LW>Но мы живём в реальном мире.

Пишите тогда в какой-нибудь буфер-в-памяти(sink), в потоковом режиме. А буфер будет писать в файл.