| |||||||||||
One at a timeOne at a timePosted Mar 9, 2004 8:08 UTC (Tue) by larryr (guest, #4030)In reply to: One at a time by mwilck Parent article: A retry-based AIO infrastructure
I think the thread that is handling accessing a floppy is going to be asleep almost all the time, so there will be plenty of time for other threads to wake up, do some stuff, and either finish or go back to sleep themselves. Larry
(Log in to post comments)
AIO as replacement for mutlithreading ? Posted Mar 9, 2004 21:47 UTC (Tue) by mwilck (guest, #1966) [Link] What are you referring to as a "thread"? An AIO request? How can other AIO requests "wake up, do some stuff" if the kernel is still handling the floppy request which blocks the single AIO entry for the process?Guess I must read the code myself. I may have put my concern in the wrong words though. One idea I have about AIO is that you can have an application behave like a multithreaded application with a singe thread. Instead of creating threads for certain IO tasks you just fire off AIO requests and they _proceed simultaneously_, as if they were driven by different threads. I wonder how that'd be possible with the serialized approach described here. Perhaps the whole notion is wrong, though?
AIO as replacement for mutlithreading ? Posted Mar 11, 2004 17:34 UTC (Thu) by larryr (guest, #4030) [Link] How can other AIO requests "wake up, do some stuff" if the kernel is still handling the floppy request which blocks the single AIO entry for the process? Most of the (wall clock) time the kernel is handling the floppy request is going to be spent sleeping (waiting for the floppy device), and while that request is sleeping another request can proceed until it either completes or has to wait for a device (sleep). Larry
|
|||||||||||