C#: блокирование вызова функции до тех пор, пока не будет выполнено условие

Question

Я разрабатываю приложение C# Winforms, часть приложения будет загружать файлы на веб-сервер с помощью AsyncUpload (используя его из-за необходимости использования обратного вызова porgress). C# программы

я получил простой цикл, который вызывает функцию загрузки

for(int i=0;i < 10 ; i++) 
{ 
    Uploadfun(); 
} 

И весело делают некоторые магии:

Uploadfun() 
    { 
    // Logic comes here 

    // webClient.UploadFileAsync runs a 2nd thread to perform upload .. 
    webClient.UploadFileAsync(uri, "PUT", fileNameOnHD); 

} 

И обратный вызов, который вызывается ш курица загрузка Асинхронный делается

Upload_Completed_callback() 
{ 
    //Callback event 
} 

Редактировать

Логика последовательности:

1. Fun вызывается (из цикла)
2. Fun логика выполнена и сделано ..
3. Возврат к циклу
4. Обратный звонок будет называться eventuall y, когда UploadFileAsync (который запускает некоторую логику в другом потоке) закончится

Проблема на третьей точке, когда выполнение возвращается в цикл for, мне нужно заблокировать цикл от продолжения до тех пор, пока callback вызывается.

Answer 1

Итак, если я правильно понял, вы хотите позвонить UploadFileAsync, а затем заблокировать, пока асинхронный вызов не ударит ваш обратный вызов. Если да, то я бы использовал AutoResetEvent т.е.

private readonly AutoResetEvent _signal = new AutoResetEvent(false); 

fun() 
    { 
    // Logic comes here 

    // runs a 2nd thread to perform upload .. calling "callback()" when done 
    webClient.UploadFileAsync(uri, "PUT", fileNameOnHD); 

    _signal.WaitOne(); // wait for the async call to complete and hit the callback  
} 



callback() 
{ 
    //Callback event 
    _signal.Set(); // signal that the async upload completed 
} 

Использование AutoResetEvent означает, что государство получает автоматически сбрасывается после того, как Set был вызван и ожидающий поток получает сигнал через WaitOne

Answer 2

В методах C# по умолчанию, поэтому вам не нужно ничего делать. Я предполагаю, что по какой-то причине вы вызываете неблокирующий метод, который запускает фоновое задание/thread/whatever и дает вам обратный вызов, когда это делается. Вы хотите называть этот асинхронный метод синхронно.

Вы можете позвонить fun изнутри обратного вызова. Что-то вдоль этих линий (псевдо-код):

int n; 

callFunTenTimes() 
{ 
    n = 0; 
    fun(n); 
} 

callback() 
{ 
    ++n; 
    if (n < 10) 
     fun(n); 
    else 
     print("done"); 
} 

Это похоже на continuation passing style.

Преимущество этого метода в том, что вы также можете сделать свой метод асинхронным без добавления дополнительных потоков, блокировок или дополнительной логики - вы просто предоставляете функцию обратного вызова, на которую может подписаться ваш клиент. Он хорошо работает в среде, управляемой событиями.

Answer 3

Проблема здесь:

for(int i=0;i < 10 ; i++) 
{ 
    fun(); <-- if we block until this function finishes here, we stop the UI thread 
} 

То, что вы делаете, является последовательным.И если вы не можете позволить себе, чтобы блокировать поток пользовательского интерфейса, переместить петлю от потока пользовательского интерфейса:

volatile downloadComplete; 

void DownloadUpdates() 
{ 
    ThreadPool.QueueUserWorkItem(state => 
     for(int i = 0; i < 10; i++) 
     { 
      downloadComplete = false; 
      webClient.UploadFileAsync(uri, "PUT", fileNameOnHD); 
      while(!downloadComplete) { Thread.Sleep(1); } 
     }); 
} 

Upload_Completed_callback() 
{ 
    downloadComplete = true; 
} 

Теперь вы можете блокировать выполнение цикла без остановки вашего UI нити, и вы также получаете выгоду от индикаторы прогресса из класса webclient.

Answer 4

Zebrabox действительно имеет право использовать WaitHandle. В то время как решение Джульетты работает, поток, выполняющий ожидание, будет потреблять значительное количество процессора пропорционально WaitHandle, который по существу будет сидеть без дела.