2011-09-15 13 views
5

sto porting C++ API codice per .NET e guardando in funzione di chiamata WaitHandle.WaitAny come un sostituto per WaitForMultipleObjects, ma quando il debug con .NET4 posso vedere che questa funzione viene agganciato inWaitHandle.WaitAny per abbinare WaitForMultipleObjects funzionalità

private static extern int WaitMultiple(
           WaitHandle[] waitableSafeHandle, 
           int msTimeOut, 
           bool exitContext, 
           bool WaitAll); 

e questo mi fa pensare che questa funzione non è sutable per la porta. Qualche altro suggerimento?

+2

Perché no? Permette di specificare anche più handle di attesa – sll

+3

Perché pensi che WaitAny non sia adatto? – dtb

risposta

3

Piuttosto la stessa firma e il comportamento, quindi è un buon candidato. Se WaitForMultipleObjects() è stato chiamato con WaitAll=true è possibile utilizzare WaitHandle.WaitAll() così

C++ WaitForMultipleObjects()

DWORD WINAPI WaitForMultipleObjects(
    __in DWORD nCount, 
    __in const HANDLE *lpHandles, 
    __in BOOL bWaitAll, 
    __in DWORD dwMilliseconds 
); 

Waits fino a quando uno o tutti gli oggetti specificati sono nel segnalata stato o l'intervallo di timeout trascorre


C# WaitHandle.WaitAny()

public static int WaitAny(
    WaitHandle[] waitHandles, 
    TimeSpan timeout, 
    bool exitContext 
) 

attese per qualsiasi degli elementi dell'array specificato per ricevere un segnale , utilizzando un periodo per specificare l'intervallo di tempo e specificando se uscire dal dominio sincronizzazione prima l'attesa.

.NET fornisce un altro metodo WaitHandle.WaitAll() ma utile quando si ha bisogno per garantire che tutti gli handle vengono ricevuti un segnale.

8

È vero che WaitHandle.WaitAny() non è abbastanza per corrispondere alla funzionalità di WaitForMultipleObjects(). Ma hai solo bisogno di usare WaitHandle.WaitAll() pure.

  • WaitHandle.WaitAny() partite WaitForMultipleObjects() chiamato con il parametro WaitAll impostato FALSE,.
  • WaitHandle.WaitAll() corrisponde a WaitAll impostato su TRUE.
2

Va bene, utilizza WaitForMultipleObjects() sotto il cofano. Che si può scoprire con questo piccolo programma di test:

using System; 
using System.Threading; 

class Program { 
    static void Main(string[] args) { 
     var waits = new WaitHandle[65]; 
     for (int ix = 0; ix < waits.Length; ++ix) waits[ix] = new ManualResetEvent(false); 
     WaitHandle.WaitAny(waits); 
    } 
} 

stessa restrizione che WaitForMultipleObjects ha. Il metodo WaitMultiple() è contrassegnato MethodImplOptions.InternalCall perché in realtà risiede all'interno del CLR. Che vuole sapere sul blocco delle attese per fornire diverse garanzie sul threading gestito. Come pompare un loop di messaggi su un thread dell'interfaccia utente per mantenere la COM felice (MsgWaitForMultipleObjects), sapere quando una richiesta remota può essere sospesa per la richiesta successiva e sapere quando un thread è in uno stato sicuro per onorare le richieste di interruzione.

Problemi correlati