Мне кажется с блокировками вы несколько путаетесь. В данном случае могут быть заблокированы 2 объекта на одной файловой операции:
1. поток, использующий синхронную операцию чтения/записи в файл
2. файл открытый для монопольного доступа
Думаю ваш вопрос не связан с п.1, т.к. это больше про параллельное программирование, а не про файлы и БД.
Файловые операции легко могут не блокировать поток - асинхронный ввод/вывод.
Файл можно открыть с монопольным доступом и с общим доступом. В общем доступе этот же файл может открыть и другое приложение одновременно с вашим.
При общем доступе вы можете блокировать какую-то область файла и работать с этой областью "монопольно".
БД открывают свои файлы в монопольном режиме.
В разных потоках одного приложения вы можете открыть файл один раз и работать с одним и тем же дескриптором файлов из разных потоков. Но это может создать кучу проблем с целостностью структуры файла, если много потоков будут не согласованно писать в файл.
Файловые операции ОЧЕНЬ медленные. Поэтому все нормальные базы данных работают через свой собственный кэш. Поэтому там, обычно нет кучи потоков, которые лопатят файл БД. Движок SQL берет данные из кэша, есть некий "менеджер кэша" - отдельный поток, которому движок дает запрос на данные, если данных в кэше прямо сейчас нет, то менеджер кэша читает данные из файла в кэш и отдает эти данные запрашиваемому потоку. Чтение файла наверняка то же идет не на прямую, а запросы на чтение ставятся в очередь и возможно какой-то другой поток (или тот же менджер кэша) по очереди читает необходимые данные. Аналогично и с записью - через кэш и последующую очередь на запись.
Если запустить MS Sql Server с настройками по умолчанию с достаточно большой по объему базой он довольно быстро отожрет в компе вообще всю свободную память (конечно, если БД меньше, чем объем ОЗУ, то всю память не отожрет). Не то что бы ему очень нужно прямо сейчас вот столько памяти (он может в это время вообще простаивать), просто он начитал данные в кэш.
Как-то так я это вижу.
