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

Я думаю, что правильный подход будет следующим: создание набора строк were 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
}

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

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

//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();

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

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

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

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

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

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

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

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

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

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

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

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

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

lock(string.Intern("FileLock:absoluteFilePath.txt"))
{
    // your code here
}

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

PS: текст 'FileLock' - это просто произвольный текст, чтобы гарантировать, что другие пути к строковым файлам не затронуты.