7.4 `thread` -- Controllo multi-thread

Questo modulo fornisce primitive di basso livello per lavorare con thread multipli (a.k.a. processi o task leggeri -- thread multipli di controllo condividono il loro spazio di dati globale. Per la sincronizzazione, vengono forniti semplici lock (a.k.a. semafori binari o mutualmente esclusivi).

Il modulo è opzionale. È supportato su Windows, Linux, SGI IRIX, Solaris 2.x, e su ogni sistema che supporta l'implementazione thread POSIX (a.k.a. ``pthread''). Ai sistemi che non possiedono il modulo thread, viene fornito il modulo dummy_thread. Che duplica l'interfaccia di questo modulo e può essere usato come un rimpiazzamento drop-in.

Questo modulo definisce le seguenti costanti e funzioni:

exception error: Sollevata da errori specifici dei thread.

LockType: Questo è il tipo per gli oggetti lock.

start_new_thread( function, args[, kwargs]): Inizia un nuovo thread e restituisce il suo identificatore. Il thread esegue la funzione function con la lista di argomenti args (che deve essere una tupla). L'argomento opzionale kwargs specifica un dizionario di argomenti a parola chiave. Quando la funzione restituisce, il thread termina silenziosamente. Quando la funzione termina con una eccezione non gestita, viene stampata una traccia dello stack ed il thread termina (ma gli altri thread continuano a lavorare).

interrupt_main( ): Solleva una eccezione KeyboardInterrupt nel thread principale. Un sotto-thread può usare questa funzione per interrompere il thread principale. Nuovo nella versione 2.3.

exit( ): Solleva l'eccezione SystemExit. Quando non viene catturata, il thread termina silenziosamente.

allocate_lock( ): Restituisce un nuovo oggetto lock. I metodi dei lock sono descritti sotto. Il lock è inizialmente sbloccato.

get_ident( ): Restituisce l'identificatore di thread' del thread corrente. Questi è un intero diverso da zero. Il suo valore non ha un significato diretto; È da intendere come un magic cookie utilizzabile ad esempio come indice per un dizionario di dati specifici per i thread. Gli identificatori dei thread possono essere riciclati quando un thread termina ed un altro thread viene creato.

Gli oggetti lock hanno i seguenti metodi:

acquire( [waitflag]): Senza argomento opzionale, questo metodo acquisisce il lock incondizionatamente, se necessario aspettando fino a che non venga rilasciato da un altro thread (solo un thread alla volta può acquisire un lock -- è la ragione della loro esistenza), e restituisce None. Se l'argomento intero waitflag è presente, l'azione dipende dal suo valore: se è zero, il lock è acquisito solo se può essere acquisito immediatamente senza aspettare, mentre se è diverso da zero, il lock è acquisito incondizionatamente come prima. Se è presente un argomento, il valore restituito è True se il lock è acquisito con successo, False altrimenti.

release( ): Rilascia il lock. Il lock deve essere stato acquisito in precedenza, ma non necessariamente dallo stesso thread.

locked( ): Restituisce lo stato del lock: True se nel caso sia stato acquisito dal qualche thread, False altrimenti.

Avvertenze:

I thread interagiscono in modo strano con gli interrupt: l'eccezione KeyboardInterrupt verrà ricevuta da un thread arbitrario. (Quando è disponibile il modulo signal, gli interrupt saranno ricevuti sempre dal thread principale).
Chiamare sys.exit() o sollevare l'eccezione SystemExit equivale a chiamare exit().
Non tutte le funzioni built-in che si bloccano in attesa di I/O permettono ad altri thread di funzionare. (Le più famose (time.sleep(), file.read(), select.select()), funzionano come previsto).
Non è possibile interrompere il metodo acquire() su un lock -- l'eccezione KeyboardInterrupt verrà sollevata dopo che lock sarà acquisito.
Quando termina il thread principale, la sopravvivenza degli altri thread dipende dal sistema. Su SGI IRIX usando l'implementazione nativa dei thread, sopravvivono. Su molti altri sistemi, vengono uccisi senza eseguire le clausole try ... finally o eseguire i distruttori degli oggetti.
Quando il thred principale termina, non esegue nessuno dei suoi soliti cleanup (eccetto per le clausole try ... finally, e i file standard di I/O non vengono aggiornati.

Vedete Circa questo documento... per informazioni su modifiche e suggerimenti.

7.4 thread -- Controllo multi-thread

7.4 `thread` -- Controllo multi-thread