DBWR must write blocks to the datafiles and ensure they get written.  These blocks are 
protected by redo in the oneline redo log.  Before we can reuse a redo log file, we must 
ensure that the blocks protected by that redo are safely and totally written to disk.

DBWR can do this in one of two ways.  Lets say DBWR has 100 blocks to write to disk.  It 
could:


   for i in 1 .. 100
   loop
      write block X to disk and wait for the OS to tell
      us the operation is totally complete (the block is
      not buffered by the OS or anything, it is on disk)
   end loop

As you can imagine, that would be slow.  For each block, we would have to wait for the OS 
to tell us the block is written.  If there was any contention on that disk (eg: another 
process was reading /writeing that disk), we would have to wait event longer.


Another way is to write the block to disk and not wait for the OS to tell us the block 
has been written.  rather, the OS will "call back" to us and tell us that block X was 
written.  The logic might look like this:

  for i in 1 .. 100 
  loop
     write block X and return immediately, don't wait
  end loop
  
  now wait for the 100 blocks to "call back" to us, let the OS
  do its work and wait.


In this case, we give the OS all of the work we want done and let it schedule it as fast 
as it can.  While it is off doing its thing, we are submitting yet more blocks to be 
written.  We can get some parallel processing going on here and things go faster.

When the OS does not support async IO, we can use mutliple processes to mimick it.  DBWR 
will use the slaves to do the syncronous writes and use many of them simultaneously.  
When the slaves are done, they call be to DBWR just like the OS would.