Quali sono i diversi aspetti da considerare quando si porta il codice da un singolo ambiente a thread a un ambiente a più thread o viceversa?

1

Desidero fornire alcune funzionalità di libreria e un'applicazione di riferimento, che verrà eseguita su una piattaforma conforme a POSIX completa di funzionalità. L'app e la libreria necessitano di comunicazione bidirezionale della porta seriale, input dell'utente da tastiera, visualizzazione utente alla console di testo e probabilmente timer.

Desidero anche fornire una guida per il porting in modo che gli utenti della libreria possano portarlo (con o senza l'applicazione di riferimento) alle proprie piattaforme, che potrebbero essere conformi o meno a POSIX e potrebbero supportare o meno thread multipli .

Mi sto occupando del problema della portabilità della piattaforma principale scrivendo codice portatile per tutto il più possibile e fornendo un livello di porting autonomo per il codice specifico della piattaforma. Nella mia guida al porting dirò all'utente di sostituire le funzioni del livello di porting con le implementazioni per la propria piattaforma.

Tuttavia, per quanto riguarda il modello di threading, ho due scelte:

  • implementare la mia applicazione di riferimento come un programma a thread singolo molto semplice (il ciclo principale eseguirà il polling della tastiera, eseguirà il polling della porta seriale, controllerà lo stato del timer e richiamerà le funzioni della libreria come necessario)
  • utilizza la libreria pthreads e ha una thread principale dell'app con thread separati per l'input dell'utente, la ricezione della porta seriale e la scadenza del timer, i quali inviano messaggi al thread della mia app principale per l'elaborazione.

Qualunque sia il modello che scelgo, dovrò spiegare agli utenti come portarlo su una piattaforma che potrebbe utilizzare un modello diverso.

Anche se utilizzo un'implementazione a thread singolo per l'app di riferimento, mi assicurerò che tutte le funzionalità della libreria siano rientranti (o pongo grosse accuse se non è possibile).

Quali considerazioni dovrei tenere a mente, nella mia implementazione e nella guida al porting? Quali informazioni vorresti se eseguissi il porting di un codice multi-thread su un singolo sistema thread o viceversa?

    
posta Vicky 19.09.2013 - 17:09
fonte

2 risposte

1

Come per tutti gli sviluppi multi-thread, l'introduzione di più thread significa che devono essere gestiti i seguenti elementi:

  1. Gestione dell'accesso simultaneo a risorse condivise per garantire coerenza
  2. Progettazione della strategia di blocco per prevenire deadlock
  3. Gestione delle risorse bloccate da thread. (ad esempio, puoi leggere la tua porta seriale da più thread contemporaneamente?)
  4. Spegnimento / gestione degli errori. Questo può introdurre molti percorsi di codice inaspettati, le risorse vengono sempre rilasciate correttamente, può verificarsi un deadlock?

Non vedo un particolare problema nel fare tutto questo su un singolo thread, dato che la tastiera e il serial possono essere fatti essenzialmente non bloccanti. Tutto si riduce alla tua biblioteca e quanto tempo impiegano le chiamate di funzione nella tua biblioteca per completare?

    
risposta data 19.09.2013 - 18:15
fonte
0

Non c'è motivo di introdurre il multithreading solo perché è necessario reagire a più sorgenti di input. È possibile attendere la tastiera, la porta seriale e il timer tramite la chiamata di sistema di selezione POSIX. Se stai utilizzando C ++, puoi utilizzare la libreria ACE Reactor.

    
risposta data 19.09.2013 - 19:41
fonte

Leggi altre domande sui tag