RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Ответить на сообщение

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> > > > > > Предлагаю сбрасывать полные имена залоченых файлов в очередь, например в RXQUEUE, а при завершении процесса удалять их оттуда... Или наоборот, сразу сбросить в очередь полный список всех файлов и каждый процесс будет удалять оттуда строки по мере их обработки. В любом случае, отсутствие дополнительных дисковых операций должно, по идее, дать прирост в скорости обработки.
> > > > > Процессы которые работают с файлами запускаются хаотично в любом количестве и не чего не знают друг о друге. Количество файлов за раннее не известно, но с течением времени будет только расти. Лочится только текущий файл, то есть с остальными файлами другие процессы могут делать что угодно. Выходит что каждый файл нужно искать отдельно в актуальном списке лоченных файлов. 
> > > > > Можно ли в очередь кидать сообщения (разными процессами), многократно их читать (каждым процессом, перед началом работы с каждым файлом), и удалять выборочно (например по индексу и т.п.)?
> > > > Удалять выборочно не получится, цитата из мануала по REXX:
> > > > В процедурах работа с очередями REXX осуществляется с помощью следующих инструкций: 
> > > > PUSH Помещает строку в начало очереди (LIFO). 
> > > > QUEUE Добавляет строку в конец очереди (FIFO). 
> > > > PULL Считывает строку из начала очереди. Если очередь пуста, то строка считывается с консоли (STDIN:). 
> > > > Чтобы получить информацию о количестве элементов, оставшихся в очереди, используйте функцию QUEUED.
> > > > Значит хранение списка лоченых файлов потребует, как минимум, создания некоторой процедуры для считывания всей очереди, удаления из ней нужной строки и сброса оставшихся данных назад... Тогда по второму варианту будет проще сделать, алгоритм примерно такой:
> > > > 1. *Один* процесс создаёт именованную очередь и отвечает за её наполнение, т.е. постоянно с некоторой периодичностью ищет новые файлы и добавляет их в конец очереди (QUEUE).
> > > > 2. Все остальные процессы просто читают с удалением строку с именем файла из начала очереди (PULL) и обрабатывают этот файл нужным образом. Если очередь пуста, то процесс ждёт появления строки, или завершают свою работу -- это как решишь сам.
> > > > Но тут есть такой момент: в документации по REXX также сказано, что синхронизация запросов (когда два процесса, имеющие доступ к одной и той же очереди, получают данные из этой очереди в порядке регистрации их запросов) возлагается на пользователя и не обеспечивается подсистемой, на время чтения все процессы для синхронизации должны выставлять какой-нибудь флаг, для совместимости на разных системах можно, например, изменять значение системной переменной...
> > > Обработка ВСЕХ файлов подряд возможна, но это скорее исключение. В большинстве случае будет проводиться обработка части файлов, выбранных по признаку (в данном случае дата зашифрованная в имени файла). Поэтому помещать в очередь нужно имена лоченных файлов (список доступных файлом макрос получает при запуске по поиску SysFileSearch).
> > 
> > Вопрос: все запускаемые обрабатывающие макросы фактически одинаковые, или у них есть отличия в параметрах поиска файлов?
> 
> Варианты скриптов, ограничены, в теории 4-10 шт (сейчас 4). По сути это аналог баз данных (точнее отдельных команд select, insert и т.п.), только на rexx. Они максимально унифицированы, все что смог сделал одинаковым до комментариев. Работа с файлами, внешними данными, передаваемым данными и т.п. - одинакова (принципиально, иначе все теряет смысл).
> 
> > > В параллельной ветке посоветовали обратить внимание на семафоры. Предварительно нашел команды по работе с ними в последней версии RexxUtil в OS/2 и в Регине. Ни когда не работал с ними. Буду изучать это направление, ближайшие пару дней.
> > Да, можно и семафорами разрулить... Но что-то меня смущает то, что при озвученной задаче количество семафоров может неконтролируемо расти, а очередь, всё-таки, будет всего одна, если что-то пойдёт не так, то почистить или удалить её можно запросто.
> 
> Согласен, есть такая опасность. Но и количество одновременно запущенных скриптов (файлов), так же ограничено системой (скользкий момент, до конца его не проработал). Берется как аксиома, что скрипты должны работать ограниченное время (максимально короткое), а после закрываться подчищая все за собой. А так же ставящие задачи не предусматривают сильного наплыва одновременно запущенных скриптов (я рассчитываю до 20 в пике).
> Но законы Мерфи ни кто не отменял. Так что готовимся к худшему :)
> 
> С семафорами, я раньше не работал. Хотя бы изучу технологию, да же если здесь не пригодиться.

_, _, _, / \ (_ / ~ ) \ / , ) / / ~ ~ ~~~