From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,d6f01a357b7f98ce X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news.glorb.com!wn13feed!worldnet.att.net!bgtnsc05-news.ops.worldnet.att.net.POSTED!53ab2750!not-for-mail Newsgroups: comp.lang.ada From: anon@anon.org (anon) Subject: Re: Direct_Io for Filesystem question Reply-To: no to spamers (No@email.given.org) References: <817032b7-4e8a-4589-9e44-00e7aef1fb06@v53g2000hsa.googlegroups.com> X-Newsreader: IBM NewsReader/2 2.0 Message-ID: Date: Thu, 23 Oct 2008 22:13:49 GMT NNTP-Posting-Host: 12.65.126.152 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1224800029 12.65.126.152 (Thu, 23 Oct 2008 22:13:49 GMT) NNTP-Posting-Date: Thu, 23 Oct 2008 22:13:49 GMT Organization: AT&T Worldnet Xref: g2news1.google.com comp.lang.ada:2474 Date: 2008-10-23T22:13:49+00:00 List-Id: A quick answer is yes. You use a user define package from the generic "Direct_IO" package to control a large precreated file to simulate a file_system. And each user would be assigned by opening a file, an index within that simulated file (disk), basically simulating a sector (record) location on that disk. This index could be store in the File-Control-Block. And example of a sequentail read for your file system could be Note: in the FCB record the file Index is store in a variable called Location. -- FS_FCB => File_System_File_Control_Block. procedure read ( fcb : in out FS_FCB ; Data : out Data_Record ) is begin FS_IO.Set_Index ( File_System_File, fcb.Location ) ; Read ( File_System_File, Data ) ; -- read will advance index pointer fcb.Location := Index ( File_System_File ) ; end if ; In <817032b7-4e8a-4589-9e44-00e7aef1fb06@v53g2000hsa.googlegroups.com>, mhamel_98@yahoo.com writes: >Hello all, > >I have a "filesystem" that I've been using for some time now and with >some free time on my hand I thought I would play around with >concurrency. I use the term filesystem very loosely, its simply an >instantiation of Direct_Io with a variant record, the first record in >a file is a header and the rest is data and it has worked well >enough. > >My approach to concurrency was instead of giving the >direct_io.file_type to a requesting process, I would create my own >file_type which really only contains a token and location value. The >token would direct the filesystem package to the actual file and the >location value which record to read/write. When an 'open' is called, >it checks to see if the file is already open and if so returns an >existing token, and if not, opens it and creates a token to perhaps be >shared with others later. All reads and writes are done using the >Direct_Io calls requiring a record index. What the internal index of >the file_type is I don't care (maybe I should?) This also works well >in a single user case. > >In the case of two readers, the second reader reads a little bit then >tosses an End_Error exception, the first reader completes normally. >Again, I'm wondering if the internal index value is relevant. I would >have thought that explicitly telling direct_io which record to read it >would not care where it last read. > >In the case of simultaneous reading and writing (only one writer >allowed), I designed the code so that when a reader opens the file, it >is told that the end of the file is where the writer is currently >located, so the reader will stop before overruning the writing >process' location, and this implementation is fine, no real time >requirements (that might be a neat addition later). When I run a test >of one reader and one writer, on the surface everything seems ok, no >errors thrown. When I go over the data later I get "discriminant >check failed" for a few records. Its as if the few moments a reader is >active, the writer tosses in garbage for the records written during >that time span. > >I guess the big question is, am I ok to use Direct_Io for this sort of >operation? It seems to me that the case of multiple readers is really >not much more than one reader doing very random reads? If anyone has >specific information on the symptoms I'm seeing, I'd really appreciate >it! > >Thanks for any advice or opinions!