Quali false idee ci sono che scoraggiano le persone usando i thread? [chiuso]

12

L'implementazione del threading in un programma è difficile, sì, tuttavia perché alcune persone non li implementeranno anche quando ce n'è una necessità evidente.

Un esempio: il programma deve caricare un set di dati da un database, la cosa da fare sarebbe fare la connessione e ottenere i dati dal database in un thread di lavoro e quindi caricarli nella GUI, lasciando il thread della GUI reattivo per l'utente .

Ma no, ho parlato con persone che sembrano pensare che i fili siano cattivi e cattivi e quant'altro e che si dovrebbero evitare a tutti i costi. Ho anche sentito che alcuni istruttori di classe sconsigliavano l'uso dei thread e quindi non volevano coprirne l'uso. CHE COSA???

Con l'hardware in multi-core, penso che dobbiamo capire meglio i thread e non aver paura di usarli. Lo trovo un argomento affascinante personalmente.

Quindi quali sono le cose che hai sentito sul threading che sono false?

multithreading

— Tony The Lion
fonte

Disadattati e underachievers non possono gestire discussioni. La vera domanda è: che cosa hai intenzione di fare al riguardo?

— Lavoro

3

Quelle non sono false idee, ma i fili dovrebbero sempre essere evitati. Esegui correttamente la tua architettura in modo che il supporto per il threading sia già stato gestito correttamente e che ogni programmatore non debba farlo da solo. Una volta che i programmatori imparano ad aggiungere un thread in ogni situazione, avrai grossi problemi.

— TP1

Permettimi di invertire la domanda. Ti sei chiesto se esistono approcci alternativi allo sfruttamento delle capacità di elaborazione parallele? Oppure sei passato direttamente al threading perché alcuni white paper lo dicevano, o forse perché è quello che i programmatori migliori sembravano essere fighi? Personalmente, mi piace l'idea di processi leggeri che si scambiano messaggi molto meglio dei thread. Sono pigro / stupido / di fretta? Sì, e lo siamo anche noi, in varia misura.

— user1172763,

19

Il threading è difficile

Sicuro. Può essere. Tuttavia, le persone hanno questa idea nella testa che è così difficile, tale da non disturbare a cercare di capirlo.

Non è impossibile.

— Steven Evers
fonte

2

Sostengo questa risposta. La gente pensa che sia difficile. Tuttavia non è quando passi abbastanza tempo a cercare di capire.

11

@Pierre, mi aspetto che la definizione di hard di molte persone sia "devi passare abbastanza tempo a cercare di capire".

— Benjol,

1

Il threading sta diventando molto più semplice con TPL e await/ asyncparole chiave :)

— Rachel,

@Pierre 303: quando passi abbastanza tempo per capire è ancora difficile , e in effetti le persone che lo comprendono meglio hanno maggiori probabilità di evitarlo il più possibile.

— Michael Borgwardt,

9

Non è la parte di threading che è difficile ma la necessità di sincronizzazione e tutto il resto che viene fornito con l'utilizzo di thread. Nel tuo esempio di GUI come fai a dire al thread principale al quale è possibile accedere al set di dati? Passi un sacco di callback? Spargi un sacco di variabili check in tutto il tuo codice? In alcuni modelli di GUI, ad esempio Silverlight, esiste qualcosa chiamato affinità di thread, il che significa che non puoi accedere agli elementi della GUI che si trovano sul thread principale da altri thread, quindi devi fare di tutto per far sapere al thread principale che determinate informazioni sono pronto per essere ulteriormente elaborato.

Non ho davvero sentito nulla di falso sui thread. Ho appena letto un sacco di casi studio situazionali sulla sincronizzazione essendo una cagna quando qualunque algoritmo che stai usando non è intrinsecamente parallelo.

— DavidK01
fonte

Nota per sé: scrivere algoritmi paralleli ... grazie.

— Droogans,

Code di messaggi (come in MFC). Tuttavia, convincere i programmatori a non sabotare la coda dei messaggi (condividendo direttamente i dati in memoria), anche quando si tratta di un reato attivabile, sembra aver fallito.

— dal

3

Il threading risolve tutti i tuoi problemi

Se hai problemi di prestazioni si dovrebbe non saltare diritto di threading.

I fili sono leggeri

I fili sono leggeri in decine e venti. Generare migliaia di thread non lo è.

Il threading è facile [Java]

È facile creare thread, ciò non significa che ne trarrai vantaggio.

— Josh K
fonte

Solo per la cronaca, Mac OS non ti permetterà (su un'installazione predefinita) di creare più di 512 thread.

— zneak,

1

Dipende molto dalla tua lingua. Generare 1 milione di thread in Erlang è appena percettibile, anche su un laptop più vecchio, per non parlare di un server moderno. E in realtà, questi non sono nemmeno solo thread, sono processi in piena regola , cioè molto più pesanti dei thread. Oltre al proprio contatore di programmi e stack di chiamate (che sono praticamente le uniche cose che un thread ha), hanno anche il loro heap e persino il loro garbage collector.

— Jörg W Mittag,

4

@ Jörg W Mittag: sono confuso dal tuo commento. In che modo erlang cambia il modo in cui il sistema operativo crea un thread o un processo?

— Steven Evers,

1

@SnOrfus: Erlang non usa i thread del sistema operativo. Ci sono tre principali implementazioni di Erlang in questo momento: BEAM, HiPE ed Erjang. BEAM e HiPE sono implementazioni native (che possono anche funzionare senza alcun sistema operativo) e implementano i propri processi. Erjang gira su JVM e implementa i processi usando la fantastica libreria Kilim.

— Jörg W Mittag,

@ Jörg W Mittag: considerando la mia domanda programmers.stackexchange.com/questions/28453/… , lo trovo molto interessante. Grazie.

— Steven Evers,

1

Alla fine perderai qualsiasi guadagno dal threading perché correggere bug pazzi che sorgeranno dall'uso di alcune librerie / funzioni che non sono thread-safe (di cui non eri a conoscenza) richiederà una sincronizzazione eccessiva.

Hai una probabilità molto più alta di incontrare bug che non sarai in grado di correggere se usi i thread allora quando non lo fai.

— Kamil Szot
fonte

Bug non risolvibili? Non ne ho mai visto uno prima ...

— Adamk, il

Non hai mai visto un bug che non riuscivi a risolvere? Nel tempo e per la paga che era disponibile?

— Kamil Szot,

Se non hai mai riscontrato un bug non risolvibile, non sei stato nel settore abbastanza a lungo. Nei miei oltre 12 anni di lavoro, ogni progetto che abbia mai visto ha almeno un bug che nessuno ha corretto e nessuno sa come riparare o persino riprodurre. Questo include il codice su cui sono stato impiegato per lavorare e il codice a cui ho accesso per leggere (codice open source). Le uniche parti di software prive di bug sono quelle lunghe meno di 2 o 3 pagine. Ma rendere tutto il tuo codice 1 o 2 pagine lunghe non risolve completamente nulla perché allora hai bug di integrazione.

— Slebetman,

1

Riassumendo il punto saggio del motivo per cui i thread sono difficili da usare: -
Cose vere 1) È necessaria la sincronizzazione e attente decisioni di progettazione su cosa bloccare e quando bloccare
2) Nessun controllo sul flusso del tempo di esecuzione
3) Debug difficile
4) (Pochissimi volte) compatibilità della piattaforma: - Esistono librerie per occuparsene

Cose false: -
1) Concetti confusi di funzioni thread-safe e re-entrant
2) I thread sembrano buoni sulla carta ma sono molto difficili da implementare

— Manoj R
fonte

Questi dovrebbero essere veri o falsi? L'OP ha chiesto quali cose non sono vere e ha spaventato le persone dal fare una programmazione multi-thread.

— Steven Evers,

in realtà non hai bisogno di blocchi o sincronizzazione. Esistono anche modelli di passaggio messaggi (ad es. Erlang, scala) e modelli STM (ad es. Clojure). Inoltre, ci sono strutture di dati thread-safe che non necessitano di blocchi (ConcurrentHashMap in Java) e primitive atomiche che non richiedono blocchi.

— Kevin

1

Se non vuoi scrivere test per il tuo codice, non usare i thread.

I thread non sono per il tipico programmatore "copia e incolla" che non comprende i fondamenti di base del sistema operativo e dell'architettura del computer. Dal momento che il 90% dei programmatori conosce solo Java, in realtà non sono le persone che dovrebbero usare i thread. Java rende i thread "facili" ma ho visto molti programmatori che pensano solo che se usassero strutture sincronizzate il loro codice funzionerebbe nei thread .... uhm no.

Detto questo, tutti devono iniziare da qualche parte, semplicemente non fare il tuo primo progetto di threading per aggiornare il server di backend di produzione della tua azienda.

— cmcginty
fonte

Puoi consigliare alcune risorse su come eseguire correttamente i thread?

— Jonathan,

Sono sicuro che questo è stato risolto. Provare ad avviare qui stackoverflow.com/questions/660621/threading-best-practices~~V~~singular~~3rd

— cmcginty

Il problema è che anche se hai una copertura dei test al 100% non avrai modo di sapere se i tuoi test copriranno tutti i possibili problemi con il modo in cui le istruzioni si alternano con le risorse condivise. D'altra parte con un'architettura nulla condivisa diventa molto più facile.

— Zaccaria K,

1

Un esempio: il programma deve caricare un set di dati da un database, la cosa da fare sarebbe fare la connessione e ottenere i dati dal database in un thread di lavoro e quindi caricarli nella GUI, lasciando il thread della GUI reattivo per l'utente .

Non vedo che questa situazione rappresenti una necessità di utilizzare il threading per almeno 4 motivi:

Il recupero dei dati dovrebbe essere molto veloce.
In molte applicazioni della linea di business, l'utente non ha nulla a che fare con l'applicazione nel giro di 1 secondo o due che sta aspettando il risultato. Inoltre, l'utente dovrà attendere il ritorno dei dati in qualsiasi modo per completare l'attività desiderata. La query d'altra parte potrebbe essere codificata in modo intelligente in modo tale da recuperare solo una pagina piena di informazioni alla volta e altre tecniche di ottimizzazione potrebbero aiutare i tempi di risposta.
Nelle interfacce basate sul web, i collegamenti possono essere resi attivi riguardo al modello di threading.
Il threading aggiunge complessità come ammetti, alcuni sviluppatori lungo la linea potrebbero non essere in grado di aggiungere funzionalità o eseguire il debug di codice complesso.

La mia opinione è: utilizzare il threading quando è necessario perché la manutenzione e l'affidabilità del software sono più preziose per un'organizzazione dell'eleganza del codice.

— Nessuna possibilità
fonte

1

Il tuo primo punto mi ricorda gli errori del calcolo distribuito ( en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing ). Un sacco di utenti possono iniziare a fare clic selvaggiamente quando devono attendere più di 1 o 2 secondi dal punto 2 per un'interfaccia che non risponde, peggiorando le cose.

— Sicuro il

@Sicuro, il link è interessante, grazie per averlo condiviso. Non sono sicuro che potremmo mai catturare l'attenzione dell'utente continuamente sull'interfaccia o persino sull'intero lavoro in questi giorni. Sono d'accordo con te sul fatto che nei siti di e-business non desideri che l'utente se ne vada affatto.

— NoChance,

Non sto parlando del focus. Quando l'utente fa clic su un pulsante e l'interfaccia si blocca semplicemente perché viene interrogato il database, senza una risposta visiva che qualcosa viene fatto, alcuni utenti tentano di fare nuovamente clic sul pulsante. E di nuovo. Quindi prova a fare clic su altri pulsanti o opzioni. Ho visto gli amministratori fare questo che dovrebbero conoscere meglio.

— Sicuro il

Ancora peggio quando la schermata dei risultati viene disegnata per la prima volta, ma mostrata vuota. Non conosco la maggior parte delle versioni attuali, ma il risultato della ricerca in Outlook meno recenti è un buon esempio negativo. Quando si avvia la ricerca, viene visualizzato "Set di risultati vuoto" o qualcosa del genere, per alcuni secondi con una base di ricerca di grandi dimensioni, che mostra i primi risultati trovati. Se sei troppo impaziente o hai fretta, sei già passato alla cartella successiva, credendo che non ci sia nulla.

— Sicuro il

1

@Sicuro, vedo il tuo punto. Quello che stai descrivendo qui mostra un buon esempio di un'interfaccia utente incoerente. Ciò che hai descritto si verifica anche quando cerchi file. Ma qual è la risposta a questa se non dire all'utente che la ricerca è già iniziata?

— NoChance,