[Gambas-user] How to lock a file

[Benoit Minisini]

On mardi 07 octobre 2008, Rolf-Werner Eilert wrote:
> Benoit Minisini schrieb:
> > On mardi 07 octobre 2008, nando wrote:
> >> There is a problem with your method.
> >> Between the execution of the KILL and the CREATION of the file,
> >> multitasking happens and another task could create the file just before
> >> the original thread executed the CREATE.
> >>
> >> In different words, if the first thread lost the CPU just after the KILL
> >> command due to multitasking and a second thread began the WHILE
> >> condition, the WHILE would not execute because the WHILE condition fails
> >> and then the file is CREATED with the user of the second thread.
> >> Then, multitasking happens and the second thread loses the CPU and the
> >> first thread continues and it will then create the file destroying the
> >> second threads information.  Anything could happen in a multitasking
> >> environment.
> >>
> >> I use directories because folder creation is a one-step process there
> >> isn't time between the two steps for
> >> another task to steal the lock in betweem code statements.
> >> An example is something like...
> >>
> >> 'create lock, this can be in a SUB with tje folder name passed in
> >>
> >> counter=100     '100 loops of 0.1 sec = 10 seconds max to try lock
> >> flag = FALSE
> >> WHILE flag = FALSE
> >>   TRY MKDIR "lock-folder-name"
> >>   IF ERROR THEN  'it failed
> >>     flag=TRUE
> >>     error.clear
> >>     WAIT 0.1
> >>     dec counter
> >>     if counter<=0 then
> >>       'you could say the the lock took too long
> >>       'you could allow a user choice to retry or blindly continue.
> >>       break   'we will assume something is locked too long
> >>     endif
> >>   else
> >>     flag=FALSE
> >>   endif
> >> wend
> >>
> >>
> >> 'unlock, this can be a SUB too
> >> TRY RMDKR "lock-folder-name"
> >> error.clear
> >>
> >> You don't need to know who has the lock because only a successful lock
> >> leads to code writing some important information for the thread that
> >> successfully locked.  The unlock must follow very shortly thereafter to
> >> release the lock and cannot hog the lock.
> >>
> >> -Fernando
> >
> > Or better method: use the LOCK / UNLOCK instruction!
>
> Yes Benoit, we know, but this is hobby :-) just having fun with an own
> algorithm...
>
>
> But I've got a question about LOCK. I didn't know it existed. A long
> time ago when I started with Linux, I learned that Linux doesn't have a
> file locking mechanism. Isn't that true anymore? Never heard or read
> about it in all these years.
>
> After all, a lot of programs still use lock files, and for instance
> there is a discussion about Firefox 3 not running correctly on terminal
> servers because it's got a new file locking method which blocks more
> than 1 users.
>
> Having a first glance at the description of LOCK, there is one thing
> which leaves at least a small pain in the neck: You have to open the
> stream before being able to try a lock. That leaves the impression that
> without checking the lock, you can read/write the file anyway. Two
> questions:
>
> Is this LOCK just a flag? (Which I can obey or not just like I feel) Or
> does it really prevent any other access (or at least writing into the
> file)?
>
> And what happens if my program "forgets" Unlocking it? Will the file
> stay locked (file system wide - until reboot) or will the Lock end
> automagically when I close the file or when the process ends that opened
> the stream?
>
> (Maybe it would be nice to insert such information into the help, too)
>
> Regards
>
> Rolf
>

The documentation you read is false and out of date. Look at the updated 
documentation in the wiki.

I cannot say more than what I already wrote there:

LOCK uses a file to create a system-wide global lock. Without using a file, it 
couldn't be system-wide.

It actually uses the lockf() POSIX file lock routine to lock the file so that 
only one process at a time can acquire the lock.

The contents of the underlying file is not important. But do not write in it, 
as acquiring the lock automatically voids the file!

LOCK returns a Stream object that you use to UNLOCK the file. 

And halting the process automatically releases the lock - Important feature!

I hope I have shown that LOCK is useful :-)

Regards,

-- 
Benoit Minisini