Многопоточная работа с файлами через DLL

← →
VEG © (2004-08-10 18:37) [0]

Хочется узнать ваше мнение, реально ли все это...
Мне необходимо реализовать систему для многопоточной работы с файлами. Я предполагаю, что это можно сделать через DLL. Как должна работать система?
На машине запущено несколько программ. Скажем, 3 программы - программа a.exe, b.exe, и c.exe. В память подгружена DLL fs.dll, и все три программы ее используют. В DLL есть общая функция, которой передаются запросы на различные действия с файлами (чтение, запись). Эта функция (точнее, функции. по функции на разные виды запроса) проверяет, есть ли поток, работающий с этим файлом. Если поток обнаружился, К владельцам потока дописывается имя запросившей программы, и ее действия загоняются в стек (или очередь, в зависимости от приоритета). Если потока не существует, он создается, и его владельцем становится запрашивающая программа.
Когда программа посылает запрос на закрытие файла, функция в DLL проверяет, есть ли еще владельцы у потока, и если нет, то поток уничтожается.
Т.е. получается, что программы a.exe и c.exe могут параллельно использовать и изменять файл z.dat, а программа b.exe будет работать с файлами s.dat и j.dat.
Соответсвенно, когда хоть одна программа использует многопоточную работу с файлами, эта DLL должна висеть в памяти в одном адресном пространстве для всех программ, т.е. все глобальные переменные в этой DLL должны быть идентичны для вызовов из любых программ. Если же DLL никто не использует, она выгружается.
Такая идея реализуема с помощью DLL? Или нужно клонить в сторону сервисов?
Совместимость важна, поэтому система должна работать как в ОС Windows NT, так и в Windows 9x.

P.S. Вам может показаться эта идея довольно адсурдной, но скажу, что я преследую несколько иные цели. DLL не будет манипулировать данными из файла, но совершенно не в таком виде, как они записаны в файле...

P.P.S. Дополнительный вопрос, касающийся этой проблемы. Система из DLL трех уровней будет сильно тормозить? Т.е. Программа вызывает функции из одной DLL, эта DLL вызывает функции DLL многопоточной работы с файлами, а эта DLL, в свою очереь, вызывает функции из DLL касательно структур данных.
Дело в том , что на мне будет лежать ответсвенность за промежуточную DLL (она будет одна). DLL первого и третьего уроня должны писать совершенно другие люди, в соответствии с SDK. Или это будет сильно тормозно?
Объемы данных большими не планируются - в среднем до мегабайта, и вообще примерно до 100Мб.

← →
Romkin © (2004-08-10 18:52) [1]

Бррр... Городить такое...
Что за работа с файлами? В любом случае, ты должен отслеживать блокировки, а то если два потока будут изменять одно и то же место в файле - ой! И dll, кстати, использовать совсем не обязательно :))

← →
Sun bittern © (2004-08-10 18:56) [2]

Касательно выше изложенного скорее всего на помощь придет технология COM. Т.е. подсчет сылок (сколько клиентов юзает) проще наверно релизуется с помощью COM. А по поводу тормозов, только голова и руки от этого зависят :)

← →
VEG © (2004-08-10 18:56) [3]

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

← →
VEG © (2004-08-10 19:07) [4]

Нет, вы не так поняли. DLL должна создавать по потоку на каждый файл, и в каждом потоке свои очереди запросов для всех программ. Прочтите, пожалуйста, внимательнее.

← →
Romkin © (2004-08-10 19:12) [5]

А зачем именно dll? И почему именно файлы?
Вот это непонятно.
Насколько я понял, постановка такая: Есть программы, которым требуется одновременный доступ к информации, содержащейся в файлах. Так?
Тогда вопрос: А извращаться-то зачем? Типичная схема работы с сервером БД, может, взять готовый и не мучиться?

← →
GanibalLector © (2004-08-10 19:14) [6]

Обратитесь к дядьке Рихтеру,в часности к ф-ции EnterCriticalSection и подобным.

← →
Romkin © (2004-08-10 19:18) [7]

GanibalLector © (10.08.04 19:14) [6] Не особо требуется :) LockFileEx никто не отменял...

← →
TUser © (2004-08-10 20:20) [8]

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

← →
VEG © (2004-08-10 20:34) [9]

Нет, не поможет. Я же говорю, в самом файле информация хранится не в том виде, в котором ее представляет DLL. Например, файл может быть объемом в 10 кб, а DLL даст доступ к 20 Мб информации, построенной на базе этого файла.

← →
sniknik © (2004-08-10 20:41) [10]

ты просто не представляеш себе возможности нынешних SQL серверов, там информации может не быть вовсе, а 20 Мб информации они тебе обеспечат. ;о)) за счет вычисляемых полей, процедур и функций.

← →
VEG © (2004-08-10 21:01) [11]

:) Все, наш говор ушел в оффтоп. Давайте по теме?

← →
Romkin © (2004-08-11 00:08) [12]

А по теме-то что?
Ответ: реально. Можно реализовать так.
Как это должно работать? Ответ: максимально удовлетворяя потребности приложений.
> DLL не будет манипулировать данными из файла, но совершенно не в таком виде, как они записаны в файле...

Ну и ладушки :)))

>Система из DLL трех уровней будет сильно тормозить?

А фиг его знает... Как напишете.
Вызов функции из dll в общем случае ничем не отличается от вызова функции в едином приложении :))

Это - ответ. Вот только что он дает?

← →
VEG © (2004-08-11 00:30) [13]

Он дает мне понять, что задуманное реально реализовать так, как я задумал, и потом не придется все переписывать;)

← →
jack128 © (2004-08-11 00:43) [14]

> Давайте по теме?
по теме [7]

← →
Fay © (2004-08-11 01:50) [15]

Вопрос - полный бред.

> DLL должна висеть в памяти в одном адресном пространстве
> для всех программ

Дико интересно, как это быдет реализовано. Не видно возмущённых реплик от Мастеров - наверное отходят от шока.

P.S.
2 jack128 © (11.08.04 00:43) [14]
2 Romkin © (10.08.04 19:18) [7]

LockFileEx
Windows 95/98/Me: Unsupported.

← →
nikkie © (2004-08-11 01:50) [16]

На машине запущено несколько программ. Скажем, 3 программы - программа a.exe, b.exe, и c.exe. В память подгружена DLL fs.dll, и все три программы ее используют. В DLL есть общая функция, которой передаются запросы на различные действия с файлами (чтение, запись). Эта функция (точнее, функции. по функции на разные виды запроса) проверяет, есть ли поток, работающий с этим файлом. Если поток обнаружился, К владельцам потока дописывается имя запросившей программы, и ее действия загоняются в стек (или очередь, в зависимости от приоритета). Если потока не существует, он создается, и его владельцем становится запрашивающая программа.

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

Дело в том , что на мне будет лежать ответсвенность за промежуточную DLL (она будет одна). DLL первого и третьего уроня должны писать совершенно другие люди, в соответствии с SDK. Или это будет сильно тормозно?

проблема не в том, что будут тормоза, а в том, что работать это не будет.

kernel32.dll
> DLL первого и третьего уроня должны писать ...

А какого уровня kernel32.dll? Просто интересно.

> LockFileEx
> Windows 95/98/Me: Unsupported
мдя. Это минус. Ну тогда в цикле LockFile пытаться сделать. Хотя я б Event"ом воспользовался.

2 VEG ©
Чё, ваще никак не то же самое?
CreateFile(PChar(B_FILE_NAME), GENERIC_READ or GENERIC_WRITE, FILE_SHARE_READ, nil OPEN_EXISTING, 0, 0)

2 GanibalLector © (10.08.04 19:14) [6]

> Обратитесь к дядьке Рихтеру,в часности к ф-ции EnterCriticalSection
> и подобным.

Critical section objects provide synchronization similar to that provided by mutex objects, except that critical section objects can be used only by the threads of a single process.

Нда. Подвергся жесткой критике. Главный вопрос, в принципе, и был в том, реально ли сделать так, чтобы DLL работала в одном адресном пространстве. Все потоки, которые, собственно, и выполняли всю работу с файлами, долджны были бы принадлежать DLL. Программа давала бы только запросы, не более.
Признаюсь, я хочу сделать необычную БД, или даже ФС.
Вот пример, как работа будет выглядеть в программе:
var z: TXFile; o: TXFileItem; data: array of byte; begin z.AssignBaseFile("MyApp", "filename.xfl"); (*MyApp - индекс нового владельца потока. Если такое имя уже сужествует, то в цикле автоматом прибавляется _N, пока имя не станет уникальным.*) o:=z.AssignObject("basic/inftags/pict.bmg"); (* Тут все очень оригинально. В самом файле filename.xfl вся ветвь inftags упакована, например, потоковым ctxf, файл pict.bmp в оригинале записан в, например, JPG, плюс еще чем-нибудь зашифрован*) o.RaedData(data); //... А здесь все закрываем ...
Вообщем, такой бред. Т.е. в файле древовидная структура данных, где каждый объект может храниться самым причудливым образом, и ветки тоже могут быть объектами. Если программист обращается к данным на высоком уровне функций, DLL сама все преобразует на лету, и выводит в нужном формате в зависимости от запроса.
На такое современные SQL серверы способны?

VEG © (11.08.04 10:29) [21]
НУ через File Mapping данные у тебя будут доступны всем процессам, что и требуется, как я понял.
А файл случайно не формата COM Storage? Там даже транзакции есть, и синхронизация доступа. Ничего и делать-то особо не надо

← →
Erik1 (2004-08-11 11:12) [23]

Вобщем идея понятна, если будет много математики и преобразований возможно SQL сервер действительно лишний.
Но зачем усложнять себе жизнь?! Почему просто ненаписать exe? Это будет отдельный процес которй очень удобно отлаживать, создать нужное количетво тредов в процессе непроблема, очереди организовать тоже просто. Недопущение второго запуска вобще без вопросов. Интерфнйс обмена с процессом ничего особо сложно непредставляет, всеравно File Mapping придется использовать. К томуже будет возможно SendMessage использовать, что бывает весьма удобно. Если хочется запускать без указания пути, то можно у нему маленький com сервер сделать для проверки состояния (работает/неработает) и проверку на работающею копию тогда делать ненадо.

Многопоточная работа с файлами через DLL Найти похожие ветки