2012-05-10 17 views
14

In Java o C# o in altri linguaggi, vi sono strutture IO non bloccanti, ad es. Per socket.Come viene implementato l'I/O non bloccante?

Così posso assegnare le mie funzioni di richiamata all'IO non bloccante e una volta che l'IO non bloccante riceve qualcosa, chiamerà le mie richiamate.

Mi chiedo come vengono implementati. Se creo un IO non bloccante, dietro la scena, Java o C# creano solo thread in background per loro? o il sistema operativo sottostante ha il supporto nativo per loro?

+0

Vedere le osservazioni qui: http://msdn.microsoft.com/en-us/library/dxkwh6zw.aspx. Sembra utilizzare un thread in background, che viene memorizzato nella cache se lo stesso contesto viene riutilizzato. – mellamokb

+0

@mellamokb dice che un contesto di esecuzione è memorizzato nella cache e riutilizzato, non dice nulla su un thread. –

risposta

18

Su Windows è presente il supporto del sistema operativo per I/O non bloccanti e Microsoft CLR ne trae vantaggio. Anche altre implementazioni CLR (mono) probabilmente lo fanno, ma non lo so per certo. Quando si esegue l'I/O asincrono su Microsoft CLR, non esiste una correlazione 1 a 1 tra le operazioni di I/O asincroni in attesa e i thread (o almeno i thread gestiti) in attesa del completamento di tali operazioni di I/O.

Vedere http://msdn.microsoft.com/en-us/library/windows/desktop/aa365683(v=vs.85).aspx per alcuni dettagli sui dettagli del layer Win32. Anche le informazioni sulle porte di completamento I/O qui: http://msdn.microsoft.com/en-us/library/aa365198(VS.85).aspx

mia comprensione è questo:

  1. comincio un'operazione asincrona di I/O su qualche thread dell'applicazione.
  2. Se non lo è già, verrà creata una coda (beh, in realtà un costrutto a livello di kernel chiamato una porta di completamento I/O, che è associata a una coda nello spazio del kernel della mia applicazione). Nel mondo .NET, un thread appositamente designato chiamato un thread della porta di completamento I/O inizierà ad attendere le notifiche di completamento I/O su quella coda. La cosa importante da notare qui è che posso fare un numero qualsiasi di richieste I/O asincrone senza aumentare il numero di porte di completamento I/O.
  3. Il sistema operativo notificherà l'applicazione al termine dell'I/O accodando un messaggio di completamento I/O sulla coda. Il thread della porta di completamento I/O gestirà quindi quel messaggio richiamando il callback del completamento dell'I/O nella mia applicazione .NET. Nel frattempo, se altri I/O sono completati, i risultati verranno accodati dietro i risultati di elaborazione correnti.

Avvertenze a quanto sopra:

  1. sono sicuro che ho avuto parte di questo male, ma credo che il senso generale di che sia corretto. Eric o qualcuno può entrare e correggermi dove sono fuori.

  2. In .NET sono presenti più thread di porta di I/O. Non ho idea di come le richieste di I/O asincrone siano allocate tra le varie porte di I/O di completamento. Potrebbe trattarsi di una funzionalità del sistema operativo (in cui l'I/O può tornare su qualsiasi porta aperta dall'applicazione).

Per Java sono sicuro che dipende dall'implementazione JVM e dal sistema operativo specifico. Non lo so quasi abbastanza per speculare oltre.

EDIT: aggiornamento storica, molti altri dettagli here

+0

Cosa intendi per 'Per C# esiste un supporto OS sottostante ...'. Il sistema operativo non lo sa.NET è in esecuzione su di esso e in teoria .NET può essere eseguito su Windows e Linux (tramite mono). – Tudor

+0

@Tudor Chiarirò –

+0

Si prega di scrivere con ulteriori dettagli – Jack