| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Многопоточная работа с файлами через DLL [Win95/98, WinME, NT4, Win2k, WinXP]
VEG © (2004-08-10 18:37:00)Хочется узнать ваше мнение, реально ли все это...
Мне необходимо реализовать систему для многопоточной работы с файлами. Я предполагаю, что это можно сделать через 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Мб.
Erik1 (2004-08-11 11:12:00) [1]Вобщем идея понятна, если будет много математики и преобразований возможно SQL сервер действительно лишний.
Но зачем усложнять себе жизнь?! Почему просто ненаписать exe? Это будет отдельный процес которй очень удобно отлаживать, создать нужное количетво тредов в процессе непроблема, очереди организовать тоже просто. Недопущение второго запуска вобще без вопросов. Интерфнйс обмена с процессом ничего особо сложно непредставляет, всеравно File Mapping придется использовать. К томуже будет возможно SendMessage использовать, что бывает весьма удобно. Если хочется запускать без указания пути, то можно у нему маленький com сервер сделать для проверки состояния (работает/неработает) и проверку на работающею копию тогда делать ненадо.
Romkin (2004-08-11 10:51:00) [2]VEG © (11.08.04 10:29) [21]
НУ через File Mapping данные у тебя будут доступны всем процессам, что и требуется, как я понял.
А файл случайно не формата COM Storage? Там даже транзакции есть, и синхронизация доступа. Ничего и делать-то особо не надо
VEG (2004-08-11 10:29:00) [3]Нда. Подвергся жесткой критике. Главный вопрос, в принципе, и был в том, реально ли сделать так, чтобы 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 серверы способны?
Fay (2004-08-11 02:23:00) [4]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.
Fay (2004-08-11 02:08:00) [5]2 VEG ©
Чё, ваще никак не то же самое?
CreateFile(PChar(B_FILE_NAME), GENERIC_READ or GENERIC_WRITE, FILE_SHARE_READ, nil OPEN_EXISTING, 0, 0)
jack128 (2004-08-11 01:57:00) [6]
> LockFileEx
> Windows 95/98/Me: Unsupported
мдя. Это минус. Ну тогда в цикле LockFile пытаться сделать. Хотя я б Event'ом воспользовался.
Fay (2004-08-11 01:54:00) [7]kernel32.dll
> DLL первого и третьего уроня должны писать ...
А какого уровня kernel32.dll? Просто интересно.
nikkie (2004-08-11 01:50:00) [8]На машине запущено несколько программ. Скажем, 3 программы - программа a.exe, b.exe, и c.exe. В память подгружена DLL fs.dll, и все три программы ее используют. В DLL есть общая функция, которой передаются запросы на различные действия с файлами (чтение, запись). Эта функция (точнее, функции. по функции на разные виды запроса) проверяет, есть ли поток, работающий с этим файлом. Если поток обнаружился, К владельцам потока дописывается имя запросившей программы, и ее действия загоняются в стек (или очередь, в зависимости от приоритета). Если потока не существует, он создается, и его владельцем становится запрашивающая программа.
чушь полная. потоки сами по себе не существуют. потоки - внутри процессов. программы - это просто файл на диске определенного формата. три работающие программы - три процесса. причем имя программы не является уникальным идентификатором процесса. давай теперь, принимая сказанное во внимание, опиши - кто что делает и что проверяет.
Дело в том , что на мне будет лежать ответсвенность за промежуточную DLL (она будет одна). DLL первого и третьего уроня должны писать совершенно другие люди, в соответствии с SDK. Или это будет сильно тормозно?
проблема не в том, что будут тормоза, а в том, что работать это не будет.
Fay (2004-08-11 01:50:00) [9]Вопрос - полный бред.
> 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.
jack128 (2004-08-11 00:43:00) [10]
> Давайте по теме?
по теме [7]
VEG (2004-08-11 00:30:00) [11]Он дает мне понять, что задуманное реально реализовать так, как я задумал, и потом не придется все переписывать;)
Romkin (2004-08-11 00:08:00) [12]А по теме-то что?
Ответ: реально. Можно реализовать так.
Как это должно работать? Ответ: максимально удовлетворяя потребности приложений.
> DLL не будет манипулировать данными из файла, но совершенно не в таком виде, как они записаны в файле...
Ну и ладушки :)))
>Система из DLL трех уровней будет сильно тормозить?
А фиг его знает... Как напишете.
Вызов функции из dll в общем случае ничем не отличается от вызова функции в едином приложении :))
Это - ответ. Вот только что он дает?
VEG (2004-08-10 21:01:00) [13]:) Все, наш говор ушел в оффтоп. Давайте по теме?
sniknik (2004-08-10 20:41:00) [14]ты просто не представляеш себе возможности нынешних SQL серверов, там информации может не быть вовсе, а 20 Мб информации они тебе обеспечат. ;о)) за счет вычисляемых полей, процедур и функций.
VEG (2004-08-10 20:34:00) [15]Нет, не поможет. Я же говорю, в самом файле информация хранится не в том виде, в котором ее представляет DLL. Например, файл может быть объемом в 10 кб, а DLL даст доступ к 20 Мб информации, построенной на базе этого файла.
TUser (2004-08-10 20:20:00) [16]Может поможет БД и транзакции. Для синхронизации обращения к одному и тому же экземпляру информации, которую ты хранишь, а?
Romkin (2004-08-10 19:18:00) [17]GanibalLector © (10.08.04 19:14) [6] Не особо требуется :) LockFileEx никто не отменял...
GanibalLector (2004-08-10 19:14:00) [18]Обратитесь к дядьке Рихтеру,в часности к ф-ции EnterCriticalSection и подобным.
Romkin (2004-08-10 19:12:00) [19]А зачем именно dll? И почему именно файлы?
Вот это непонятно.
Насколько я понял, постановка такая: Есть программы, которым требуется одновременный доступ к информации, содержащейся в файлах. Так?
Тогда вопрос: А извращаться-то зачем? Типичная схема работы с сервером БД, может, взять готовый и не мучиться?
VEG (2004-08-10 19:07:00) [20]Нет, вы не так поняли. DLL должна создавать по потоку на каждый файл, и в каждом потоке свои очереди запросов для всех программ. Прочтите, пожалуйста, внимательнее.
| |
Страницы: 