Неблокируемое ожидание без TPL в 3.5

Question

Как я могу выполнить ожидание без блокировки потока и без TPL 'ContinueWith? Напр. в 3,5? Я знаю о портированной версии TPL для 3.5 (командой RX), но мне любопытно узнать, какие примитивы для потоков я могу использовать для этого (... что происходит в сценах TPL). И что ContinueWith альтернативы в TPL?

// будет ли этот обработчик блокировать поток во время операции асинхронного ввода-вывода?

public class AsyncHandler : IHttpAsyncHandler 
    { 
     public void ProcessRequest(HttpContext ctx) 
     { 
      // not used 
     } 

    public bool IsReusable 
    { 
     get { return false; } 
    } 

    public IAsyncResult BeginProcessRequest(HttpContext ctx, 
              AsyncCallback cb, 
              object obj) 
    { 
     AsyncRequestState reqState = 
          new AsyncRequestState(ctx, cb, obj); 
     AsyncRequest ar = new AsyncRequest(reqState); 
     ThreadStart ts = new ThreadStart(ar.ProcessRequest); 
     Thread t = new Thread(ts); 
     t.Start(); 

     return reqState; 
    } 

    public void EndProcessRequest(IAsyncResult ar) 
    { 
     AsyncRequestState ars = ar as AsyncRequestState; 
     if (ars != null) 
     { 
      // Some cleanup 
     } 
    } 
} 
class AsyncRequestState : IAsyncResult 
{ 
    public AsyncRequestState(HttpContext ctx, 
           AsyncCallback cb, 
           object extraData) 
    { 
     _ctx = ctx; 
     _cb = cb; 
     _extraData = extraData; 
    } 

    internal HttpContext _ctx; 
    internal AsyncCallback _cb; 
    internal object _extraData; 
    private bool _isCompleted = false; 
    private ManualResetEvent _callCompleteEvent = null; 

    internal void CompleteRequest() 
    { 
     _isCompleted = true; 
     lock (this) 
     { 
      if (_callCompleteEvent != null) 
       _callCompleteEvent.Set(); 
     }   
     if (_cb != null) 
      _cb(this); 
    } 

    public object AsyncState 
    { get { return (_extraData); } } 
    public bool CompletedSynchronously 
    { get { return (false); } } 
    public bool IsCompleted 
    { get { return (_isCompleted); } } 
    public WaitHandle AsyncWaitHandle 
    { 
     get 
     { 
      lock (this) 
      { 
       if (_callCompleteEvent == null) 
        _callCompleteEvent = new ManualResetEvent(false); 

       return _callCompleteEvent; 
      } 
     } 
    } 
} 

class AsyncRequest 
{ 
    private AsyncRequestState _asyncRequestState; 

    public AsyncRequest(AsyncRequestState ars) 
    { 
     _asyncRequestState = ars; 
    } 

    public void ProcessRequest() 
    { 
     //calling webservice or executing sql command asynchronously 
     AsyncIOOperationWithCallback(state => 
             { 
              ((AsyncRequestState)state.Context)._ctx.Response.Write("Operation completed"); 
              _asyncRequestState.CompleteRequest(); 
             }, _asyncRequestState); 

    } 
} 

Answer 1

Ждать, по определению, является «блокировкой». Вы можете подождать еще один поток, но вы бы заблокировали , что нить. Если «без блокировки» вы имеете в виду , не блокируя UI, тогда вы можете подождать еще один поток и сообщить об этом в пользовательский интерфейс через event (который будет обрабатывать InvokeRequired/BeginInvoke, если необходимо).

Если это не то, о чем вы просите, предоставьте более подробную информацию.

Answer 2

То, как вы обычно имеете дело с асинхронной операцией без блокировки потока, заключается в том, чтобы ваша асинхронная операция поддерживала обратный вызов. TPL действительно не делает ничего волшебного здесь; если базовые операции не поддерживают некоторую форму обратного вызова в какой-то момент, вы все равно застреваете с чем-то, что в конечном итоге блокируется. Классический «Begin/End» Asynchronous Programming Model отлично справляется с этим требованием.

Когда TPL действительно сияет, это обеспечивает лучшую поддержку обработки/агрегации исключений и позволяет создавать более сложные модели продолжения (такие как ContinueWhenAll или ContinueWhenAny.) Существует также новая поддержка отмены, включая предотвращение последующего продолжения. Однако само продолжение - это не что иное, как обратный вызов в более привлекательном, более чистом пакете.