Modelli di threading quando si parla di dispositivi hardware

Question

Modelli di threading quando si parla di dispositivi hardware

#1 da (2 voti)

4

Quando si scrive un'interfaccia all'hardware su un bus di comunicazione, i tempi di comunicazione possono talvolta essere fondamentali per il funzionamento di un dispositivo. Pertanto, è comune per gli sviluppatori creare nuovi thread per gestire le comunicazioni.

Può anche essere una pessima idea avere un sacco di thread nel tuo sistema, e nel caso in cui tu abbia più dispositivi hardware potresti avere molti thread che non hanno il controllo dell'applicazione principale.

Certamente può essere comune avere due thread per dispositivo, uno per la lettura e uno per la scrittura.

Sto cercando di determinare i pro e i contro dei due diversi modelli a cui riesco a pensare e mi piacerebbe l'aiuto della comunità di Programmers.

Ogni istanza del dispositivo riceve i propri thread (o condivide un thread per un dispositivo di comunicazione). Può esistere un thread per la scrittura e uno per la lettura. Le scritture richieste a un dispositivo dall'API sono memorizzate nel buffer e gestite dal thread del writer. Il thread di lettura esiste in caso di blocco delle comunicazioni e utilizza le richiamate per trasferire i dati letti all'applicazione. Il tempo delle comunicazioni può essere gestito dal thread delle comunicazioni.
I dispositivi non hanno i propri thread. Invece le richieste di lettura e scrittura sono accodate / bufferizzate. L'applicazione chiama quindi una funzione "DoWork" sull'interfaccia e consente a tutte le operazioni di lettura e scrittura di svolgersi e attivare le loro richiamate. Il tempo viene gestito dall'applicazione e il conducente può richiedere di essere chiamato ad una determinata frequenza specifica.

I professionisti per l'elemento 1 includono un controllo più fine della tempistica a livello di comunicazione a scapito del controllo di cosa sta accadendo a livello di applicazione di livello superiore (che per un sistema in tempo reale può essere terribile).

I pro per l'articolo 2 includono un migliore controllo sui tempi dell'intero sistema per l'applicazione, a scapito di consentire a ciascun guidatore di gestire la propria attività.

Se qualcuno ha esperienza con questi scenari, mi piacerebbe sentire alcune idee sugli approcci utilizzati.

multithreading

posta Fuzz 18.11.2011 - 02:00

fonte

1 risposta

Leggi altre domande sui tag multithreading

E i sistemi ALM, gli ERP e i prodotti incorporati? Iniezione di dipendenza: solo per oggetti a istanza singola?

score 2 · Accepted Answer

Ci sono tre schemi di contestazione generalmente considerati come modelli di concorrenza .

1. Oggetto attivo
Se si intraprende il primo approccio, è ulteriormente possibile incapsulare l'esistenza del thread "dietro" l'oggetto (o il contesto) e l'API rimane accessibile per consentire all'applicazione di interrogare e comunicare. Questo è chiamato come modello Oggetto attivo . Le chiamate primarie di lettura / scrittura rese dall'applicazione possono essere rese bloccanti o non bloccanti in base ai requisiti. Tuttavia, renderlo non-bloccante è dove il modello di oggetto attivo è un must.

2. Pool di thread
D'altra parte, se esiste un vincolo serio sul numero esatto di thread rispetto a un modello alternativo può essere usato come " modello di pool ". Questo metodo richiede che le attività debbano essere chiaramente astratte e messe in coda. Ogni volta che un thread di lavoro termina, prende la prossima attività migliore dalla coda.

3. I / O asincrono
Il terzo modello è denominato I / O asincrono dove mostra minore accoppiamento tra le attività di esecuzione dell'IO e l'applicazione.

L'oggetto attivo rende la vita dell'applicazione abbastanza semplice. Dove come pool di thread riguarda l'esecuzione disciplinata. L'I / O asincrono serve essenzialmente a ridurre al minimo l'overhead di comunicazione (o piuttosto assume una comunicazione minima).

C'è molta letteratura su ciascuno di questi argomenti, quindi non sto andando molto a lungo qui - tuttavia, aggiungerei se ci sono domande specifiche.

Mentre alcuni dei puntatori che ho dato sono in JAVA, i pattern sono praticamente implementati in C o C ++.

Questi schemi sono basati su principi fermi e convalidati (come la maggior parte dei modelli di progettazione) che dovrebbero contribuire a focalizzare l'attenzione sul design.