• Maybe here someone can reveal something about FlushProcessWriteBuffers() function.
    Description in MSDN so broad that says exactly nothing. And there is nothing in the whole web.

    This function is not like any ordinary function in WinAPI. I suppose that functionality provided by this function was needed in some particular place inside .NET. And included in WinAPI for this sole purpose - to be used somewhere inside .NET.
    And where such functionality can be necessary? I think that this is TPL Smile
    Or maybe GC. Anyway asking in other places is senseless Smile

    What type of memory barrier is executed on processors?

    Is this function synchronous? I.e. when control returns from this function, have all other processors already executed interrupt handler? I.e. are all writes already visible when function returns?

    What is assumed use? Or how it is used inside .NET (TPL)?

    Maybe some other info?

    Thank you for answers
    Dmitriy V'jukov
    Thursday, December 06, 2007 10:49 AM

All replies

  • This really doesn't have much to do with Parallel Extensions.  The Windows SDK forum would be more appropriate, let me know I can move it there.  This method is new to Vista and Windows Server 2008, so it wouldn't be used by all versions of .NET, if any.  This method also appears not to be used by Parallel Extensions.


    Are you hoping that it does something specific?


    Thursday, December 06, 2007 2:39 PM
  • Yes, please, move it to "Windows SDK".

    I think/hope that FlushProcessWriteBuffers() maybe is similar to rcu_synchronize() of RCU implementation in Linux kernel.
    And I also hope that moderators here don't ban for mention of Linux Smile

    Dmitriy V'jukov
    Thursday, December 06, 2007 2:58 PM
  • In .NET and C# you've got the volatile keyword to ensure the compiler/processor doesn't reorder the instruction, and Thread.MemoryBarrier to ensure all processor caches are flushed to RAM.


    In most cases, simply using the lock keyword perform the memory barriers for you (Monitor.Enter and Monitor.Exit both invoke memory barriers.  If all access to a shared member is wrapped in a lock statement using the same locking object; there's no need for volatile with the current CLR.


    Thursday, December 06, 2007 3:36 PM
  • No.
    If FlushProcessWriteBuffers() works as I think it works - it far more powerful than silly Thread.MemoryBarrier().
    For example with FlushProcessWriteBuffers() you can implement reader-writer mutex with no heavy memory barriers or Interlocked RMW operation on reader side at all. So it will be practically costless for readers.
    Or you can easily implement efficient object life-time management scheme with costless acquire/release operations.
    Unfortunately it's unclear how FlushProcessWriteBuffers() actually waorks. There is just some strange function without description in MSDN...

    Dmitriy V'jukov

    Saturday, December 22, 2007 10:39 AM