Многопоточность и доступ к файлам

[progua]

Здравствуйте.
Я написал несколько десятков шаблонов. Их суть такова: каждый шаблон заходит в папку на компе, берет одну статью из файла и публикует на определенный сайт.
Брать статью с удалением я не могу, так как публикация может быть неудачной и жалко терять статью. Поэтому, я сначала ее беру, а потом перемещаю в другую папку (например temp). Потом, если публикация удачная, то статью из папки temp удаляю. Вроде тестил, все работает норм, но меня терзает один вопрос:
Если я одновременно запущу 15 шаблонов, может ли быть такое, что два шаблона одновременно обратятся к одной статье?
То есть, я беру статью и сразу следующим экшеном ее перемещаю в другую папку. Вроде доля секунды, но все же.

 

[doc]

может

 

[progua]

может

Как не допустить такое? Запускать каждый шаблон вручную не хочу. Может есть другой выход?

 

[doc]

Пути к статьям в список. Брать построчно пути со списка с удалением.
Можно реализовать выбор статьи и её перемещение в temp через код и залочить его.
Можно попробовать прописывать выбранную статьи в глобальную переменную. А между выбором и записью в эту переменную поставить проверку, которая будет смотреть, нет ли такой статьи уже в этой глобальной переменной. Но тут, вроде как тоже есть лазейка, в которой могут потоки столкнуться.

Но это так, теория. Подобного рода микромоменты мне не просто даются

 

[doc]

Здравствуйте.
Я написал несколько десятков шаблонов. Их суть такова: каждый шаблон заходит в папку на компе, берет одну статью из файла и публикует на определенный сайт.
Брать статью с удалением я не могу, так как публикация может быть неудачной и жалко терять статью. Поэтому, я сначала ее беру, а потом перемещаю в другую папку (например temp). Потом, если публикация удачная, то статью из папки temp удаляю. Вроде тестил, все работает норм, но меня терзает один вопрос:
Если я одновременно запущу 15 шаблонов, может ли быть такое, что два шаблона одновременно обратятся к одной статье?
То есть, я беру статью и сразу следующим экшеном ее перемещаю в другую папку. Вроде доля секунды, но все же.

А вообще, если так подумать, даже если несколько потоков обратятся к одной статье, только один сможет её перенести. И только он будет с ней работать. Остальные посыпятся на перемещении. Может не красиво, но не критично. Общая последовательность запланированной работы нарушена не будет

 

[amyboose]

В данном вопросе надо использовать класс mutex. Он позволяет создавать объект блокировки на уровне системы (в отличие от класса lock, который создает её на базе одного процесса) таким образом, что любое приложение, обращающееся к данному системному объекту блокировки класса mutex (в нашем случае в код внедряется работа с файлом) будет ждать того момента, пока другой поток не закончит с ним работу (подробнее на msdn ищите).
P.S. разработчикам зенки тоже не мешало бы его реализовать.
P.S.S. также есть реализации чтения файла в многопоточности без каких-либо проблем при работе с ReaderWriterLockSlim, но запись там в 1 поток может идти.