Comprensione dei blocchi e dei quadri non bloccanti

5

Qualcuno potrebbe aiutarmi a capire qual è la differenza tra i blocchi e i quadri non bloccanti?

Finora, ho capito che quando una richiesta arriva a un framework di blocco crea un nuovo thread per quella richiesta e lo elabora, se la seconda richiesta arriva al server prima che la prima abbia terminato l'esecuzione creerà un altro thread.

Ora per il server non bloccante quando una richiesta arriva a un server web non creerà un thread ma attenderà il completamento di una richiesta e nel caso in cui un'altra richiesta arrivi a un framework prima che sia terminata l'esecuzione non sarà in grado di elaborare prima che restituisca il risultato della prima richiesta.

Un'altra domanda che ho è esattamente ciò che accade con la seconda richiesta in un framework non bloccante il browser aspetta solo che il server risponda fino a quando la richiesta scade o qualcos'altro accade?

Se i framework non bloccanti possono elaborare una richiesta alla volta, in che modo le app web create con framework non bloccanti elaborano più richieste rispetto a quelle create con framework di blocco (supponendo che l'affermazione precedente sia corretta). Significa che per ogni istanza del framework di blocco sul nostro server dovremmo effettivamente implementare più istanze di framework non di blocco?

    
posta Havir 17.04.2012 - 21:44
fonte

3 risposte

4

Che cos'è un framework non di blocco?

Spiegalo come se fossi 5: immagina di voler effettuare un deposito sul tuo conto bancario. Entrate e notate che non c'è coda di attesa.

Il segno sul bancone dice: "Bancomat non bloccante". Cammini e chiedi al cassiere di processare il tuo deposito, il cassiere risponde: "Sono occupato con un'altra transazione, riprova più tardi".

Aspetti un po 'di tempo e riprova più tardi. Prendi la tua decisione se vuoi continuare a provare a far processare la tua transazione o no. Si prova e la quinta volta che si tenta, la transazione viene elaborata immediatamente.

Il "Blocker teller" ti avrebbe detto di "stare in coda come coda FIFO". Il teller non bloccante dice: "riprova più tardi". Con quale cassiere bancario preferiresti interagire e perché?

Definizione: un framework non bloccante fornisce un servizio e restituisce immediatamente un risultato invece di aspettarsi che gli altri programmi richiedano l'attesa di una risorsa.

In altre parole: quando un programma lato client effettua una chiamata al framework, la chiamata verrà sempre restituita immediatamente con qualsiasi risposta che ha per te senza aspettarti di stare lì ad aspettare qualcosa. Questa garanzia è piacevole per i programmatori che non vogliono preoccuparsi di programmare intorno alla situazione in cui il framework si aspetta di attendere per 5 minuti.

Un esempio di programmazione concreto: supponiamo che il tuo framework voglia fornire un accesso reciprocamente esclusivo a un file salvato sul lato server. Un esempio di "chiamata non bloccante" sarebbe try_lock . Se il lato client vuole accedere al file, il framework risponde: "No, riprova più tardi", invece di metterti in coda e aspettarti di stare lì ad aspettare.

Il lato client continua a provare per il blocco, finché non lo ottiene, una volta che lo ottiene, fa il suo business e lo sblocca. Il vantaggio di questo è che qualunque cosa tu provi ha un effetto immediato.

Svantaggi ai framework non bloccanti: quando c'è troppo lavoro da fare per un framework non bloccante, i client vengono respinti e l'equità non viene applicata, solo i client che danno il server al server la maggior parte ottiene l'accesso al servizio. Non è giusto.

    
risposta data 01.05.2015 - 17:22
fonte
1

Did I get it right?

Penso che tu abbia fatto il backward.

"bloccare" si riferisce al divieto di altre cose dal procedere durante l'elaborazione di un'attività.

Un server ascolta una porta per una richiesta. Quando ne riceve uno, può (a) elaborare la richiesta (non ascoltare più richieste mentre lo fa, bloccare ulteriori richieste fino al completamento del lavoro) o (b) generare un thread per gestire la richiesta e tornare immediatamente all'ascolto sulla porta per ulteriori richieste.

In alternativa, potrebbe inviare la richiesta a un thread già generato in un pool di thread che sta gestendo.

    
risposta data 18.04.2012 - 02:55
fonte
0

Penso che quello che stai descrivendo confonda due cose diverse: i meccanismi di chiamata sincrona / asincrona e il schema di progettazione del reattore ( che è un modo per un'applicazione di servizio di lunga durata per gestire più richieste di servizio).

Il blocco è un altro nome per una chiamata sincrona in cui il chiamante attende fino a quando l'attività termina prima di riprendere.

Non-blocking è un altro nome per una chiamata asincrona in cui il chiamante ritorna immediatamente dopo aver effettuato la chiamata e può quindi essere informato tramite un evento (o callback) quando l'attività è terminata.

    
risposta data 18.04.2012 - 03:49
fonte

Leggi altre domande sui tag