Qual è la differenza tra QueueUserWorkItem() e BeginInvoke(), per eseguire un'attività asincrona senza tipi di ritorno necessari

Question

Seguendo la domanda BeginInvoke()/EndInvoke(), ci sono grandi differenze nelle prestazioni/nient'altro tra Delegato. BeginInvoke() e utilizzando QueueUserWorkItem() per richiamare un delegato in modo asincrono?

Answer 1

http://blogs.msdn.com/cbrumme/archive/2003/07/14/51495.aspx

dice:

"Un fatto sorprendente è che questo è anche il motivo per Delegate.BeginInvoke/ EndInvoke sono così lento rispetto al tecniche equivalenti come ThreadPool.QueueUserWorkItem (o UnsafeQueueUserWorkItem se si utilizza per le implicazioni sulla sicurezza e si desidera essere veramente efficiente. Il codepath per BeginInv oke/EndInvoke si trasforma rapidamente nel codice di elaborazione del messaggio comune del percorso di remoting generale . "

Answer 2

La cosa più importante che posso pensare con QueueUserWorkItem è che si deve utilizzare il tipo WaitCallback delegato, che guarda difficile se si dispone già di un'istanza SomeRandomDelegate e alcune args. La buona notizia è che si può risolvere questo problema con una chiusura:

ThreadPool.QueueUserWorkItem(
    delegate { someDelegate(arg1, arg2); } 
); 

Questo modello assicura anche che si ottiene una corretta tipizzazione forte al momento della compilazione (a differenza di superamento di un arg object stato a QueueUserWorkItem e la colata nel metodo di destinazione). Questo modello può essere utilizzato anche quando si chiama metodi direttamente:

ThreadPool.QueueUserWorkItem(
    delegate { SomeMethod(arg1, arg2); } 
); 

Ovviamente, senza un EndInvoke equivalente, anche voi non può ottenere un valore di ritorno di nuovo fuori a meno che non si chiama un metodo/generare un evento/etc alla fine del tuo metodo ... su una nota correlata, devi stare attento con exception handling.

Answer 3

Non ci dovrebbero essere grandi differenze, penso anche che BeginInvoke/EndInvoke generato per un delegato utilizzi il pool di thread da eseguire.

Answer 4

Non ci dovrebbero essere differenze di prestazioni, poiché sia ​​Delegate.BeginInvoke che ThreadPool.QueueUserWorkItem verranno eseguiti su un thread pool di thread.

La più grande differenza è che se chiamate BeginInvoke, siete obbligati a chiamare EndInvoke ad un certo punto. Al contrario, ThreadPool.QueueUserWorkItem è "fire and forget". Ciò ha vantaggi e svantaggi. Il vantaggio è che puoi dimenticartene. Lo svantaggio è che non si ha modo di saperlo, a meno che non si aggiunga il proprio meccanismo di sincronizzazione/notifica, una volta completata l'attività.

Answer 5

L'EndInvoke() ha un comportamento utile ma raramente menzionato - è genera nuovamente tutte le eccezioni non gestite che il delegato generato nel contesto del thread originale in modo da poter spostare la logica di elaborazione delle eccezioni nel codice principale.

Inoltre, se il delegato ha parametri out/ref, verranno aggiunti alla firma EndInvoke() che consente di ottenerli quando il metodo termina l'esecuzione.

Answer 6

Se si chiama ThreadPool.QueueUserWorkItem, le eccezioni generate nell'oggetto di lavoro non saranno gestite sul thread in background (a meno che non vengano catturate in modo esplicito). In .Net 2 e successivi, questo terminerà l'AppDomain.

Se si chiama delegate.BeginInvoke(), le eccezioni vengono messe in coda per essere nuovamente generate quando viene chiamato EndInvoke(). Se non si chiama EndInvoke(), le eccezioni sono essenzialmente memoria "trapelata" (come qualsiasi altro stato non rilasciato dall'operazione asincrona).