On Tue, Jul 16, 2002, Muli Ben-Yehuda wrote about "Re: device files implementing mmap": > This is one that I'll have to benchmark (small read + mmap vs. large > read), but it still doesn't solve the synchronization issue. How does
You *will* need to use a system call that blocks until data is available (after all, system calls are the interface between the kernel and user space...), so a "small read" will do just like any other system call... At least in this case you don't need to do two system calls. > the double buffer technique solve it? The double buffer technique is used when the kernel passes data to the user in an mmap, but then wants to write new data and doesn't know if the user has read yet the last data; So two buffers are kept: the kernel writes to one, the user reads from the other, and the roles of the two buffers are switched on each read (or whatever it is called) system call. I was thinking of the /dev/epoll driver (http://www.xmailserver.org/linux-patches/nio-improve.html) as an example of this, but it's probably not very relevant to your situation (which I don't think I still understand completely...) > This is turning into a mystery. Pretty much every sound/video driver > out there does this 'mmap into a ring buffer and let user space read > it', they can't all be racy! More digging into the code is required. I didn't read sound-driver any code, so maybe I'm not the right person to answer this... But I'm not sure how much race protection a sound driver would need. Consider my read() interface (for example), a 100K circular buffer, and an application being notified (as a result of that read()) that it can now read 10K of data starting in postion 12345 in the buffer. The worst thing that could happen (synchronization-wise) is that the application waits too long before it finally uses that data, and before it does the driver already circles around the entire buffer, overwriting the same location with new data. This "problem" will manifest itself as "skips" in sound recording when the computer is very busy - I don't think this is such a serious problem... But in this case, the driver could play safer: the driver knows a skip will occur and can take steps (such as trying to flow-control the actual device). Why? Because the driver knows the last range which it returned; It doesn't know that the user program actually read that range yet, but it knows for sure that the user program hasn't read beyond that range. A conservative driver not wanting to lose any data might not overwrite any data in the last returned range before a new range is requested by a further read() (obviously, this semantics will need to be explained to the driver users, because they will need to use all the data given by one read before they can call read() again). -- Nadav Har'El | Tuesday, Jul 16 2002, 7 Av 5762 [EMAIL PROTECTED] |----------------------------------------- Phone: +972-53-245868, ICQ 13349191 |"I don't use drugs, my dreams are http://nadav.harel.org.il |frightening enough." -- M. C. Escher ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
