From owner-freebsd-hackers Fri May 12 0:26:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9DF4E37B7AA for ; Fri, 12 May 2000 00:26:15 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e4C7w6329338; Fri, 12 May 2000 00:58:06 -0700 (PDT) Date: Fri, 12 May 2000 00:58:06 -0700 From: Alfred Perlstein To: Ville-Pertti Keinonen Cc: FengYue , hackers@FreeBSD.ORG Subject: Re: Why this works? Message-ID: <20000512005806.A29302@fw.wintelcom.net> References: <20000511210915.A38341@Hamilton-ppp44812.sympatico.ca> <864s84cq35.fsf@not.demophon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <864s84cq35.fsf@not.demophon.com>; from will@iki.fi on Fri, May 12, 2000 at 08:09:02AM +0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Ville-Pertti Keinonen [000511 22:49] wrote: > > fengyue@bluerose.windmoon.nu (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 - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message