Quali sono i meriti relativi all'implementazione di un modello di "continuazione" in stile Erlang in C #

3

Quali sono i relativi meriti ( o demeriti ) per l'implementazione di un modello di "continuazione" in stile Erlang in C #. Sto lavorando a un progetto con un numero elevato di thread con priorità Lowest e mi chiedo se il mio approccio potrebbe essere completamente sbagliato.

Sembrerebbe che ci sia un limite superiore ragionevole al numero di thread di lunga durata che ogni processo "dovrebbe" generare. Detto questo, non sono sicuro di cosa segnali il punto di non ritorno per troppe discussioni o quando schemi alternativi come "Continuazione" sarebbero più adatti.

In questo caso, molti dei thread eseguono una piccola quantità di lavoro e poi dormono fino a quando non si svegliano di nuovo ( Es. Heartbeat, spurghi cache, ecc ... ). Questo continua per tutta la vita del processo.

    
posta JoeGeeky 30.11.2011 - 20:57
fonte

1 risposta

4

Un modello di thread è davvero più per quando un'attività è in esecuzione continua. Quello che stai descrivendo è più di un modello di evento. In risposta a un timer trascorso, tu scorrere una volta una funzione, quindi il timer viene resettato. Hai solo un numero sufficiente di thread per gestire gli eventi in corso in un dato momento e puoi avere una tonnellata di timer in attesa senza nemmeno accorgertene.

Le continue sono una sorta di soluzione temporanea per consentire di mantenere lo stato nella programmazione funzionale, ma lo stato di conservazione è ciò che gli oggetti sono tutti. Memorizza tutto ciò che ti serve in un campo e sarà disponibile la prossima volta che l'evento scatta.

    
risposta data 30.11.2011 - 21:43
fonte

Leggi altre domande sui tag