* Ville-Pertti Keinonen <[EMAIL PROTECTED]> [000511 22:49] wrote:
>
> [EMAIL PROTECTED] (FengYue) writes:
>
> > I've 3 small programs. First one writes 4K of data contains 'A's into a
> > file /tmp/pagetest and then lseek() to the begin of the file.
> > Second one writes 4K of 'Z' into the same file /tmp/pagetest and
> > then lseek() to the begin of the file. They both do that in a tight
> > loop. Now, the third program reads 4K of data from /tmp/pagetest
> > and exit if the 4K data does not contain all 'A's nor 'Z's. 3 programs
> > run concurrently on the same machine (3.4). No lock in the code whatsoever,
> > and all 3 programs use pure write() and read(). I thought the third
> > program would exit pretty quickly since the data in the file may contain
> > mixed of 'A's and 'Z's, but it has been running for hours and nothing
> > happened. Could someone kindly explain this? I was told that this is
> > because the pagesize is 4096 in the kernel, so that read()/write() 4K of
> > data will not get context switched until the call is compeleted.
> > Is that right?
>
> Not quite. If FreeBSD didn't perform locking, operations affecting
> single filesystem blocks would probably be atomic (as long as the
> userland buffer is in memory).
>
> However, FreeBSD does perform locking in read(2) and write(2) for
> local files, so your third program should never fail and exit.
>
> Note that the system call interface does not guarantee reads or writes
> to be atomic, this just happens to be how it is implemented at the
> moment.
Afaik several Unix standards mandate this behavior, Linux doesn't
follow this standard though.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
