none
@The client thread management with synchronous call and asynchronous call?

    Question


  • Hello EveryBody,
     
    I want to ask some questions about the client side thread management .
     
    Normally, with a synchronous wcf client call, the call will blocked in a remote procedure call.
     
    Now the client thread will blocked. Then the call returns and the client thread resume.
     
    Now I have a asynchronous client call(Let us say it ClientRequest), the client request will not be blocked and the remote service will return the result throught a call back function(let us say it ClientCallback).
     
    For all we known, there is a main UI thread in the GUI application and only the main UI thread can change the control's properties. But if I use the asynchronous wcf client call, I can change the control's properties
     
    in the ClientCallback operation.
     
    I want to know whether the Windows Communication Foundation does something? What's it does?
     
    Thank you for your help!
     
    Regards.
     
    David
     
     
     
     
     
     
     

     

    • Edited by DavidPeng Friday, December 02, 2011 3:46 AM
    Friday, December 02, 2011 3:30 AM

Answers

  • If you're using event-style asynchronous calls (calling OperationAsync, result in the OperationCompleted event), then the callback is dispatched to the same calling thread if there is a synchronization context active (which is the case on UI threads) - in this case you don't need to worry about dispatching the call to the UI context, you can simply change the UI controls on the event handler directly.

    If you use the Begin/End-style async calls (call BeginOperation, passing a callback in the call; on the callback call EndOperation), then there are no guarantees on which thread the callback will be invoked. It's possible that it's invoked at the UI thread, it's possible that it's not, so you need to use the dispatcher to guarantee that the call to the UI controls will be made in the correct thread.


    Carlos Figueira
    • Marked as answer by DavidPeng Friday, December 02, 2011 6:22 AM
    Friday, December 02, 2011 5:27 AM
    Moderator

All replies

  • If you're using event-style asynchronous calls (calling OperationAsync, result in the OperationCompleted event), then the callback is dispatched to the same calling thread if there is a synchronization context active (which is the case on UI threads) - in this case you don't need to worry about dispatching the call to the UI context, you can simply change the UI controls on the event handler directly.

    If you use the Begin/End-style async calls (call BeginOperation, passing a callback in the call; on the callback call EndOperation), then there are no guarantees on which thread the callback will be invoked. It's possible that it's invoked at the UI thread, it's possible that it's not, so you need to use the dispatcher to guarantee that the call to the UI controls will be made in the correct thread.


    Carlos Figueira
    • Marked as answer by DavidPeng Friday, December 02, 2011 6:22 AM
    Friday, December 02, 2011 5:27 AM
    Moderator
  • : )

    Thank you very much!

     

     

     

    Friday, December 02, 2011 6:23 AM