Как Заблокировать файл и избежать чтений, в то время как он пишет

Ваш вопрос действительно заставил меня задуматься.

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

Пока фоновый рабочий запускает прочь, вы можете заставить потоки веб-приложения возвращать значения db до тех пор, пока файл действительно не существует.

Я опубликовал очень простой пример этого на GitHub .

Не стесняйтесь дать ему шанс и дайте мне знать, что вы думаете.

К вашему сведению, если у вас нет git, вы можете использовать svn, чтобы вытащить его http://svn.github.com/statianzo/MultiThreadFileAccessWebApp

У вас есть способ определить, какие файлы создаются?

Допустим, каждый из этих файлов соответствует уникальному идентификатору в вашей базе данных. Вы создаете централизованное хранилище (Singleton?), Где эти идентификаторы могут быть связаны с чем-то запираемым (Dictionary). Поток, которому необходимо читать / писать в один из этих файлов, делает следующее:

//Request access
ReaderWriterLockSlim fileLock = null;
bool needCreate = false;
lock(Coordination.Instance)
{
    if(Coordination.Instance.ContainsKey(theId))
    {
        fileLock = Coordination.Instance[theId];
    }
    else if(!fileExists(theId)) //check if the file exists at this moment
    {
        Coordination.Instance[theId] = fileLock = new ReaderWriterLockSlim();
        fileLock.EnterWriteLock(); //give no other thread the chance to get into write mode
        needCreate = true;
    }
    else
    {
        //The file exists, and whoever created it, is done with writing. No need to synchronize in this case.
    }
}

if(needCreate)
{
    createFile(theId); //Writes the file from the database
    lock(Coordination.Instance)
        Coordination.Instance.Remove[theId];
    fileLock.ExitWriteLock();
    fileLock = null;
}

if(fileLock != null)
    fileLock.EnterReadLock();

//read your data from the file

if(fileLock != null)
   fileLock.ExitReadLock();

Конечно, потоки, которые не следуют этому точному протоколу блокировки, будут иметь доступ к файлу.

Блокировка объекта Singleton, конечно, не идеальна, но если вашему приложению требуется глобальная синхронизация, то это способ ее добиться.

Я думаю, что правильный подход будет следующим: создать набор строк, где u сохранит текущее имя файла , чтобы один поток обрабатывал файл за раз, примерно так

//somewhere on your code or put on a singleton
static  System.Collections.Generic.HashSet<String> filesAlreadyProcessed= new  System.Collections.Generic.HashSet<String>();


//thread main method code
bool filealreadyprocessed = false
lock(filesAlreadyProcessed){
  if(set.Contains(filename)){
    filealreadyprocessed= true;
  }
  else{
     set.Add(filename)
  }
}
if(!filealreadyprocessed){
//ProcessFile
}

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

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

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