Algoritmi - Consulenza su come costruire algoritmo Client

Allora io sono solito svolgere programmazione multithread in C#, e multi-task "simulata" in C su microcontrollori (ma questa è un altra orribile storia) non ho minimamente esperienza su Python; ma i punti base sono sempre gli stessi.
Devi pensare ad un processo come un contenitore di thread, il processo più semplice si compone di un solo thread. Quando avvi un programma generalmente questo è single thread, durante l'esecuzione del main thread questo può generare altri thread che per quello che interessa a te, ad una prima analisi, non sono altro che programmi che vengono eseguiti in parallelo al processo principale. Un thread può accedere a determinate aree di memoria del processo principale, ma implementa uno stack proprio.
Prima di iniziare a scrivere il listato del tuo programma, mettiti a tavoli e determina quali operazioni ha senso vengano eseguite in parallelo, e soprattutto determina la priorità di risorse (es. Se un thread si occupa di registrare i dati sul DB non potrà farlo finché il thread che si interfaccia con la telecamera non gli avrà fornito i dati da registrare)

Per il resto su internet hai solo l'imbarazzo della scelta tra guide e spiegazioni riguardo la programmazione asincrona.

Ti ringrazio per l'aiuto, mentre aspettavo una tua risposta mi sono messo a studiare un pochino l'argomento e questo è quello che ho capito (ti prego di correggermi se sbaglio):

Ho bisogno di un Thread principale che solitamente è il main thread, e solitamente si lancia con il main, successivamente dentro questo processo devo lanciare i miei thread per la lettura dei sensori, nel mio caso specifico avrò 3 thread:

- Uno per la lettura continua del sensore per il conteggio delle persone
- Uno per la lettura continua del sensore di localizzazione
- Uno che controlli costantemente lo stato della porta seriale

Questi 3 thread fanno cose indipendenti e quindi non è necessario che comunichino tra loro.

Questi 3 thread appena rilevano un evento lo comunicano al server, il quale essendo sempre in ascolto sul canale si preoccupa di leggere l'evento e decidere cosa farne, o meglio in quale tabella del DB andare ad archiviare i dati.

Corretto? Grazie mille

Senza conoscere le specifiche del sistema, si, può essere un implementazione valida.

Ho un dubbio riguardo la gestione condivisa di una risorsa, sicuramente tu che hai esperienza in questo ambito potrai chiarirmelo.

I 2 thread riguardanti i sensori di localizzazione e conteggio delle persone in caso di eventuali aggiornamenti, dovranno comunicare con il server attraverso un socket, solo che il server è sempre in ascolto in attesa di un evento, potrebbe quindi essere possibile che il conteggio delle persone e la localizzazione della persona debbano essere inviati allo stesso tempo al server, come posso gestire questo? dovrò mettere una Lock o semaforo sull'uso del socket? o si fa in un altro modo?

Lasciare che sia solo il thread principale ad inviare i dati, quelli secondari potrebbero solo reperirli e caricarli nella memoria del processo, può andare?

Si, mi sembra una buona soluzione ma rimango ancora confuso sulla condivisione delle variabili e quando usare le chiamate di funzione Lock o semafori, perché comunque i miei thread legati ai sensori salveranno le loro letture dentro determinate variabili, che però poi devono essere prese dal thread principale e inviate al server giusto? Non avrei comunque bisogno di gestire l'accesso alle variabili in cui andrei a salvare le letture?