Perché è un cattivo design designare un thread per inviare dati su un socket e l'altro per ricevere dati?

5

I hanno pubblicato una domanda su SO se due thread possono eseguire simultaneamente un send() e un recv() sullo stesso socket. Mi è stato detto che, mentre potevano, l'implementazione di questo era un esempio di un design molto povero.

Il mio fondamento logico è che i pacchetti devono essere inviati ogni 20ms, quindi non posso aspettare finché non avrò ricevuto qualcosa prima di inviare qualcosa. Ho pensato che la designazione di un thread per eseguire l'invio renderà più semplice mantenere questo intervallo di 20ms non toccato da qualsiasi overhead di elaborazione non correlato.

Perché è una cattiva idea e quali sono i progetti migliori?

    
posta gaazkam 24.05.2017 - 22:20
fonte

1 risposta

9

Non è necessariamente una cattiva progettazione, ma in un'applicazione con molte connessioni aumenterà il consumo del thread (probabilmente fino al punto in cui non è possibile creare più thread).

Per supportare un numero elevato di socket con un piccolo numero di thread, verrai indirizzato a un IO asincrono, utilizzando seleziona (2) chiamata di sistema.

Se aspetti solo alcune connessioni e vuoi assicurarti che il tuo mittente non sia bloccato da un ricevitore, allora due thread vanno bene.

MA , tieni presente che hai nessuna garanzia che lo scheduler Linux eseguirà il tuo mittente ogni 20 millisecondi. Potrebbe avvicinarsi, a seconda di quanti altri thread sono in esecuzione (attraverso tutti i processi nel sistema) e quale priorità assegnare al thread. Tuttavia, a meno che tu non utilizzi un sistema operativo in tempo reale, il tuo mittente potrebbe subire ritardi per un periodo di tempo arbitrario.

    
risposta data 24.05.2017 - 23:17
fonte

Leggi altre domande sui tag