locked
non-cooperative blocking on Concurrency runtime synchronisation primitives RRS feed

  • Question

  • Hello,

    We have following problem with Concurrency runtime. We have to synchronise UI layer with the computing layer. If the Concurrency Runtime synchronisation primitives are used everywhere, there is a risk that the synchronisation primitive will execute lenghty computing routine on the UI thread, which impacts application responsiveness. If the CRITICAL_SECTION is used everywhere, the synchronization primitive will block even if it could continue with other planned work package instead of blocking, if the synchronization primitive is used inside the computing thread.

    Ideally one would have additional lock method at each of the concrt synchronisation primitive to always block, which would be called from UI threads.

    Thanks, Vojtech

    Monday, June 11, 2012 2:43 PM

Answers

  • Concurrency::critical_section (or any of the other synchronization primitives in the concurrency runtime) would simply block waiting to acquire the lock when called from the UI thread. It will not execute any computation on the UI thread. It should be noted that we do not pump Windows messages while being blocked. That means the UI would be unresponsive for the duration of blocking.

    --Krishnan (Microsoft)

    Monday, June 11, 2012 5:42 PM

All replies

  • Concurrency::critical_section (or any of the other synchronization primitives in the concurrency runtime) would simply block waiting to acquire the lock when called from the UI thread. It will not execute any computation on the UI thread. It should be noted that we do not pump Windows messages while being blocked. That means the UI would be unresponsive for the duration of blocking.

    --Krishnan (Microsoft)

    Monday, June 11, 2012 5:42 PM
  • Just to clarify, the blocking behaviour mentioned above is true for all threads (not just UI thread). Co-operative blocking just informs the scheduler that the task on a thread is blocked. The scheduler responds by executing another workitem on a different thread so as to maintain the specified concurrency level.

    --Krishnan (Microsoft)

    Monday, June 11, 2012 5:46 PM