Re: Why this works?
* 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
Re: Why this works?
* Sergey Babkin [EMAIL PROTECTED] [000512 15:23] wrote: Alfred Perlstein wrote: * Ville-Pertti Keinonen [EMAIL PROTECTED] [000511 22:49] wrote: [EMAIL PROTECTED] (FengYue) writes: 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, 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. Sounds like one more of these subtle weirdnesses in Linux that annoy me so much :-( This weirdness is intentional, it's a shortcut for speed taken at the expense of real unix compatibility. Solaris seems to be another example a system with not quite atomic writes. The writes themselves seem to be atomic but in append mode the positioning at the end of file is not atomic with writes. So when appending to a log file from multiple sources the messages tend to overlap (be written at the same position). That's why I use FreeBSD, it works. :) -- -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
Re: Why this works?
This is a silly question, but, Is there anyway to do read/write on the same file without the kernel lock? Thanks! On Fri, 12 May 2000, Alfred Perlstein wrote: * Sergey Babkin [EMAIL PROTECTED] [000512 15:23] wrote: Alfred Perlstein wrote: * Ville-Pertti Keinonen [EMAIL PROTECTED] [000511 22:49] wrote: [EMAIL PROTECTED] (FengYue) writes: 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, 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. Sounds like one more of these subtle weirdnesses in Linux that annoy me so much :-( This weirdness is intentional, it's a shortcut for speed taken at the expense of real unix compatibility. Solaris seems to be another example a system with not quite atomic writes. The writes themselves seem to be atomic but in append mode the positioning at the end of file is not atomic with writes. So when appending to a log file from multiple sources the messages tend to overlap (be written at the same position). That's why I use FreeBSD, it works. :) -- -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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Why this works?
Hello, 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? I can attach the code if it's necessary. Thanks FengYue To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why this works?
[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. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
