Re: Asynchronous I/O completion ports vs multi-threading
liormessinger@gmail.com wrote:
Hi everyone,
I am facing a problem where Asynchronous I/O completion ports using it
might help me
but I'm still debating whether to start on this method of development.
I have to write a data (video) to a file, one frame at a
time. Currently I grab the frames on one thread, and perform all of
the file writes on a background thread. But - the writes still
slow down the whole machine.
Do you think that asynchronous I/O completion ports would help here?
if so, could you explain why? for me it seemed that they probably just
doing the same thing - doing the I/O operation on a different thread.
Or am I missing anything?
In a word, no. It's unlikely that using IO Completion ports would help
given that you have a single producer/single consumer model.
What generally does help, is to use FILE_FLAG_NO_BUFFERING, which requires
that you write disk-sector-aligned data, and do those writes using async
I/O (but not IO completion ports - they wouldn't help). If your data is not
naturally disk-sector blocked, then you'll prabably have to implement a
re-blocking scheme that copies parts of frames into large, sector-aligned
buffers (e.g. 64K or larger), starting writes on buffers as they become full
while simultaneously filling the next buffer with new data.
You may simply be at the limit of your disk system as well, in which case no
amount of clever async programming is going to save you - you may simply
need a faster disk. How large are the frames and what's the frame rate?
For example, fuill resolution NTSC video requires 27Mb/s write speeds -
unless you have a fast RAID controller with multiple fast SAS/SATA/SCSI
drives, you won't get anywhere near that write speed for more than a
fraction of a second (long enough to fill up all the write buffers on the
disk(s)).
-cd