From owner-freebsd-hackers Thu May 11 22:16:12 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (vpn.iscape.fi [195.170.146.67]) by hub.freebsd.org (Postfix) with ESMTP id 8864137B707 for ; Thu, 11 May 2000 22:16:09 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id IAA37633; Fri, 12 May 2000 08:09:02 +0300 (EEST) (envelope-from will) To: fengyue@bluerose.windmoon.nu (FengYue) Cc: hackers@freebsd.org Subject: Re: Why this works? References: <20000511210915.A38341@Hamilton-ppp44812.sympatico.ca> From: Ville-Pertti Keinonen Date: 12 May 2000 08:09:02 +0300 In-Reply-To: fengyue@bluerose.windmoon.nu's message of "12 May 2000 05:47:30 +0300" Message-ID: <864s84cq35.fsf@not.demophon.com> Lines: 28 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message