File locking

[Rookie]

If I have multiple processes (parent+1 or more child processes) that are
reading a file at the same time (fopen("path.txt","r") - do I have to
implement mutual exclusion requiring only one process have access to the
file at a time?

[Måns Rullgård]

"Rookie" <do***********@rediffmail.com> writes:

If I have multiple processes (parent+1 or more child processes) that are
reading a file at the same time (fopen("path.txt","r") - do I have to
implement mutual exclusion requiring only one process have access to the
file at a time?

If you are only reading, no. If reading and writing, or more than one
process is writing, and you want consistent results you'll need some
kind of locking.

--
Måns Rullgård
mr*@mru.ath.cx

[David Schwartz]

"Rookie" <do***********@rediffmail.com> wrote in message
news:ck**********@gist.usc.edu...

If I have multiple processes (parent+1 or more child processes) that are
reading a file at the same time (fopen("path.txt","r") - do I have to
implement mutual exclusion requiring only one process have access to the
file at a time?

You only have to implement mutual exclusion if your processes need
exclusive access. You can have multiple processes concurrently reading and
writing to a file without using mutual exclusion if you don't mind seeing
old data, new data, or mixtures of both.

You the kernel doesn't ever force you to use mutual exclusion. You only
need it if you can't meet one of your requirements without it.

DS

[Rookie]

> If you are only reading, no. If reading and writing, or more than one

process is writing, and you want consistent results you'll need some
kind of locking.

I just wanted to clarify one thing - multiple processes reading from the
file will not cause the file pointer to be pointed to different positions
especially when there is a context switch between processes.

Ex. Suppose a parent forks two children A and B and both have file pointers
initialized to the start of the same file by the parent. If process A was
reading from the start of file to say a point X in the file and now if
process B starts executing and reads from the same file, will B's copy of
the file pointer point to the start of the file or will it point to X?

[Gordon Burditt]

>I just wanted to clarify one thing - multiple processes reading from the

file will not cause the file pointer to be pointed to different positions
especially when there is a context switch between processes.
ANSI C does not guarantee support for multiple processes.
Ex. Suppose a parent forks two children A and B and both have file pointers
initialized to the start of the same file by the parent. If process A was
reading from the start of file to say a point X in the file and now if
process B starts executing and reads from the same file, will B's copy of
the file pointer point to the start of the file or will it point to X?

On a POSIX system, the file pointer (in both) will point to X plus
however much B read, assuming that A does all its reading, stops,
and then B does all its reading. If they interleave, you have a
potential mess.

If each process opens the file itself (after the fork(), on a POSIX
system), they have independent file pointers.

If the parent opens the file before the fork(), the two processes
with the file open after the fork() will share a file pointer.
at the OS level. I'm not sure what happens at the stdio level.

Gordon L. Burditt

[Chris Torek]

In article <news:ck**********@gist.usc.edu>
Rookie <do***********@rediffmail.com> wrote:

Ex. Suppose a parent forks two children A and B and both have file pointers
initialized to the start of the same file by the parent.
In comp.lang.c, we do not have fork(). :-)
If process A was reading from the start of file to say a point X
in the file and now if process B starts executing and reads from the
same file, will B's copy of the file pointer point to the start of
the file or will it point to X?

In comp.unix.programmer, we have POSIX, which says that if the
underlying file descriptor is shared, so is the seek offset. If
only the file (not the descriptor) is shared, the seek offsets are
independent. The dup(), dup2(), and fork() calls all share the
file descriptor. Separate open()s do not.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.