OS: solaris
shell: bash

I have a UNIX shell script which appends new text to a file.  Multiple
instances of this program may run concurrently, hence there is a
possiblity that 2 or more instances (say S1 and S2) of this shell
script will be modifying the file at the same time.


I want to make sure that S1 can finish appending it's changes to the
file, before S2 starts to append its changes.


How do I handle this concurrently update issue so that the changes made



by S1 and S2 are not interpersed with each other's?

John Smith wrote:

> I want to make sure that S1 can finish appending it's changes to the
> file, before S2 starts to append its changes.

> How do I handle this concurrently update issue so that the changes made
> by S1 and S2 are not interpersed with each other's?

Some possibilities:

--Use the presence of another file in the filesystem as a lock.
--Have them both write to a daemon that serializes the file contents.
--Change the design so they don't touch the same file.

Chris

Chris wrote:
Some possibilities:

--Use the presence of another file in the filesystem as a lock.
if i use a lockfile, i can only restrict access to the file by
terminating the S2.  How do I make S2 "busy-wait" for S1 to finish such
that S1 and S2 are serialized?

--Have them both write to a daemon that serializes the file contents.
--Change the design so they don't touch the same file.

"John Smith" <wleung7@gmail.com> writes:

> Chris wrote:
> Some possibilities:
>
> --Use the presence of another file in the filesystem as a lock.
> if i use a lockfile, i can only restrict access to the file by
> terminating the S2.  How do I make S2 "busy-wait" for S1 to finish such
> that S1 and S2 are serialized?

This is done automatically by the lock syscall.

From the shell, you'd use a tool that'd call it.

For example, on unix you can use flock(1):

#!/bin/bash
file=/tmp/example
line="Random line ${RANDOM}"
flock "${file}" bash -c "echo \"${line}\" >> \"${file}\""




You can also try:

flock --timeout=60 "${file}" \
      bash -c "sleep 10;echo \"waiter ${RANDOM}\">>\"${file}\"" &
flock --timeout=60 "${file}" \
     bash -c "echo \"quicker ${RANDOM}\" >> \"${file}\""


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may
technically be entitled to claim that this product is
ten-dimensional. However, the consumer is reminded that this
confers no legal rights above and beyond those applicable to
three-dimensional objects, since the seven new dimensions are
"rolled up" into such a small "area" that they cannot be
detected.

* "John Smith" <wleung7@gmail.com>
| if i use a lockfile, i can only restrict access to the file by
| terminating the S2.  How do I make S2 "busy-wait" for S1 to finish
| such that S1 and S2 are serialized?

procmail (http://www.procmail.org/) has a 'lockfile' binary which
creates the lockfile in an atomic fashion.  Probably the OS has
something like that?

If you use a non-atomic wait a la
  while test -f lockfile ; do
    sleep 1
  done
  touch lockfile
you will get bitten by the race condition sooner or later.

R'

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pascal Bourguignon <usenet@informatimago.com> writes:

> "John Smith" <wleung7@gmail.com> writes:
>
>> Chris wrote:
>> Some possibilities:
>>
>> --Use the presence of another file in the filesystem as a lock.
>> if i use a lockfile, i can only restrict access to the file by
>> terminating the S2.  How do I make S2 "busy-wait" for S1 to finish such
>> that S1 and S2 are serialized?
>
> This is done automatically by the lock syscall.

lock(2) isn't implemented by all systems (e.g. Linux).  The SUS/POSIX
lockf(2) (or fcntl(2) F_SETFL/F_GETFL operations) are most portable,
and work over NFS.  There's also the older and less useful flock(2).


Regards,
Roger

- -- 
Roger Leigh
                Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFD9OZhVcFcaSW/uEgRAra/AKCU/K3CRYYXARFyR4Bju3BzW9hgiwCfVXZi
jM3tjgp8kl5PY90n5YtFkZ0=
=0s6L
-----END PGP SIGNATURE-----