Re: Behavior of flock() oriented procedures

Aaron Hsu <arcfide@xxxxxxxxxxx> wrote:
I am trying to make some wrappers for file locking in order to use them
in another language. However, I cannot figure out the proper semantics
of flock oriented procedures. Specifically, the use of open() and what
happens when a file descriptor is locked.

If I lock a file descriptor using either flock() or open(), then
obviously the file will remain locked in this manner at least until I
close the file, but is there a standard behavior for what happens to the
lock *after* I close the file descriptor? If I close the file
descriptore without explicitly calling flock() with the unlock message,
does this mean that the file will still have the lock on it, or does
this mean that the file will automatically be unlocked?

If the process that holds the lock closes the file the lock vanishes
without any explicit unlocking. All forms of locking work that way.

It would work better for my purposes if the lock remained until an
explicit unlock command,

But the moment you close the file the file descriptor you accessed
the file with loses its meaning (and the number gets re-used the
for the next file you open). So you can't unlock it anymore!

but I want to know if this is behavior that I can
expect over the UNIX platforms in general, or if this is different?

It might be nice for your purposes. But consider the consequences
if a lock would continue to exist until an explicit "unlock" would
be done. Open files get closed automatically the moment the process
that opened them exits, and therefor also the lock vanishes. If the
lock would continue to exist there would be no process anymore that
could send such an "unlock" command. It would be extremely simple
to write a "denial of serveic program" that locks a lot of impor-
tant files and the exits.

You could argue that on exit of a process an implicit unlock should
be done to avoid that scenario. But if you have a process that for-
gets to unlock a file but continues to runs for the next ten weeks
that still would keep every other process from at least writing to
the file for that time. Only someone with root priveleges could
either kill that process or at least undo the lock.

The main platforms of Interest would be OpenBSD, Linux, Mac OS X, and
Solaris, but I would want to consider others as well, such as AIX, if
only to know if there was a lot of difference.

I don't think its any different on any of these systems, sorry. But
perhaps if you write what exactly you want to achieve someone may
come up with an idea that is feasible...

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@xxxxxxxxxxx
\__________________________ http://toerring.de
.

Relevant Pages

  • Behavior of flock() oriented procedures
    ... If I lock a file descriptor using either flock() or open, ... descriptore without explicitly calling flockwith the unlock message, ...
    (comp.unix.programmer)
  • Re: Refresh Problem
    ... If I wait 3 seconds between mouse clicks on the lock / unlock button, ... workstation is looking at a current copy of the data. ... MESSAGEBOX statement after all of the database lookups have been done ...
    (microsoft.public.fox.programmer.exchange)
  • Re: A scoped lock/unlock implementation in C++.
    ... mutex_locker wrapping the same mutex, more than one thread won't share ... But beyond that it will still work with thread local mutex_locker instances, since no two threads can have a nonzero lock count anyway. ... When entering a locked region, if the last entry is negative, you know ... In case of unlocks even the unlock count is insignificant. ...
    (comp.programming.threads)
  • Re: [PATCH] Remove softlockup from invalidate_mapping_pages.
    ... These block devices are very likely to have just one ... Being locked for read is very unlikely because mdadm would have already ... memory reclaim could lock the page, ... core is free to unlock the page when the IO completes, ...
    (Linux-Kernel)
  • Re: Why are Boost thread mutexes so slow compared to Pthreads?
    ... Don't let unlock() happen automatically for unexpected throws ... ENOTRECOVERABLE returned on subsequent lock()) to expose corruption. ... A thrown exception may not be a fatal error per se, ... There's no reason why this function ...
    (comp.programming.threads)