Re: [MacPerl] file-locking algorithm (fwd)

[mark@cheers.jsc.nasa.gov (Mark Manning/Muniz Eng.)]

According to David McWherter:
> 
> I believe that multiple programs can have the same file open for writing,
> as long as they promise only to modify certain portions of the file.  This
> is a more sophisticated feature of the MacOS file manager.  I think that
> an app can ask that it has exclusive read rights on a file as well...

Yes, multiple programs can have a file opened at the same
time on a Mac.  I've done it before.  And I've overwritten
the same information in a record by two separate programs.
Never tried the exclusive read rights on a file.  However,
in the classes I've attended on writing databases there was
a good algorithm on record locking which I've used before.
It went like this:

When two or more people are to use the same database and
you do not want to have an external file locking mechanism
then you can include an additional field in each record.
This field is set and cleared by whomever is using the
database and attempting to write to a particular record.
This is a rather convoluted methodology but it works:

If all they want to do is to read the database then it is
read, the locking field is ignored, the information is
returned to the user, the database is closed, and the
program exits.  You are done.

If they want to write to the database then the program
first reads in the record information from the record.  In
the record (the first thing actually) is a record locking
field.  This field can contain various things but they have
to relate to the requests in some manner.  In it's simplest
form this could be a single byte with a zero or one being
stored into it.  Zero meaning the record is free and one
meaning it is in use.

Once the record locking field has been read in there is a
cycle of read-write-read which you get into where you read
the locking field's information, check it to see if the
record is locked.  If not - lock it.  Then read it again to
make sure someone else hasn't just unlocked it while you
were attempting to lock it or if someone else locked the
field while you were trying to lock it.  (This is why you
need different id numbers for each person.  You use the id
number to identify whether or not the program was
successful.)  Anyway, when, after a write, the read returns
that you now own the record you go ahead and re-read the
record to make sure the old information hasn't changed
(because if it has you are supposed to not overwrite the
new information and instead are supposed to just display
the NEW information).  Only if the information hasn't
changed do you then write the new information into the
database, clear the lock flag, and release the database for
further use.  Otherwise, you have to release the lock,
display the new information, allow the user to make their
changes (again) and then try to update the record again.

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch