[RC5] LIFO? Is this true?

gindrup at okway.okstate.edu gindrup at okway.okstate.edu
Mon May 18 09:43:27 EDT 1998

     I've been told that the 2kB locking granularity in MS: VB, Access, 
     FoxPro, and SQL Server are a result of granularity in Share.Exe.  
     I'm not a DOS or Windows systems programmer anymore (I prefer 
     systems that are a little less "accreted".) but have always accepted 
     this claim.  For those non-MS DBMSs that run on top of MS OSes, I've 
     been told that some low-level variant of page-locking and emulated 
     record-locking is used.
     If it is not the case that Share (and VShare) internally lock on 2kB 
     boundaries, I will be much happier as this will allow us to avoid a 
     race condition that emulating record-level locking is causing us in 
     automatic data-gathering in Access (which MS will readily tell you 
     is unsuited for automatic anything)...
     Prepending is, of course, unnecessary for implementing LIFO.  For 
     FIFO, however, the fetches could be prepended and flushes could 
     truncate the file.  Alternatively, if a modern OS had some easy way 
     to move the front of the file around, that would do.  I wasn't very 
     clear what I meant...
            -- Eric Gindrup ! gindrup at okway.okstate.edu

______________________________ Reply Separator _________________________________
Subject: Re[2]: [RC5] LIFO?  Is this true?  
Author:  <rc5 at llamas.net> at SMTP
Date:    5/16/98 1:38 AM

At 12:14 PM 5/11/1998 , Eric Gindrup wrote:
>     Clients "should" do record-level locking.  Unfortunately on MS OSes, 
>     the finest OS-supported locking is one cluster which is much larger 
>     than a block record in the buff-* files.  Other OSes don't seem to 
>     have this idiotic limitation.
Also not true.  Since MS-DOS 3.1, there has been an API call (provided by 
SHARE.EXE or network software) to lock any length byte range on any byte 
offset in a file.  There are no cluster or record locking API calls.  In 
Win32, see the "LockFile" API call.
>     Appending is a trivial operation in a lot of real filesystems.  
>     Prepending is not.  Implementing the buff-* files as LIFOs was 
>     trivial when the v1 and v2 clients were specified.  Implementing the 
>     buff-* files as FIFOs would have required more development time 
>     because verifying any code, even CompSci101 data structures, 
>     requires more time than not having to verify it.  At the time this 
>     architectural decision was made, time was better spent on other 
>     endeavours.
Prepending is unnecessary to support LIFO.  I can't think of anything that 
prepending would be useful for, thus explaining it's non-existence in most 
operating systems (it could be implemented just as easily as appending is).
 Even though the current LIFO scheme has an implied data-structure, it is
still a data structure and in many ways is just as hard to code as an 
explicit linked-list stack would be.  Also, the buff-* files have a file 
header in them anyway.  Obviously, what's done is done and it is certainly 
not worth any effort to change it.  Any buff-* file format change requires 
replacing all the clients in shared environments (simultaneously).  I'm 
just a simple system programmer, so I enjoy discussing shared-access file 
structures. *grin*
- Sanford 
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net 
rc5-digest subscribers replace rc5 with rc5-digest

To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest

More information about the rc5 mailing list