{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Quelle fonction utiliser pour créer un nouveau thread en Rust ?","acceptedAnswer":{"@type":"Answer","text":"La fonction thread::spawn du module std::thread permet de créer un nouveau thread d'exécution. Elle prend une closure en paramètre et retourne un JoinHandle qui permet d'attendre la fin du thread avec la méthode join(). Cette fonction est le point d'entrée principal pour la programmation concurrente basée sur les threads en Rust."}},{"@type":"Question","name":"Que retourne la méthode join() appelée sur un JoinHandle ?","acceptedAnswer":{"@type":"Answer","text":"La méthode join() retourne un Result où T est le type de retour de la closure du thread. Si le thread se termine normalement, on obtient Ok(valeur). Si le thread a paniqué, on obtient Err contenant les informations du panic. Cela permet de récupérer les résultats du thread ou de gérer ses erreurs de manière sécurisée."}},{"@type":"Question","name":"Pourquoi utiliser le mot-clé move avec une closure passée à thread::spawn ?","acceptedAnswer":{"@type":"Answer","text":"Le mot-clé move force la closure à prendre ownership des variables qu'elle capture au lieu de les emprunter. C'est essentiel avec thread::spawn car le nouveau thread peut vivre plus longtemps que la portée où les variables sont définies. Sans move, le compilateur refuse car il ne peut pas garantir que les références seront valides pendant toute la durée de vie du thread."}},{"@type":"Question","name":"Quel est le rôle du trait Send en Rust ?","acceptedAnswer":{"@type":"Answer","text":"Le trait Send indique qu'un type peut être transféré en toute sécurité d'un thread à un autre. La plupart des types primitifs et des structures composées uniquement de types Send sont automatiquement Send. Les types comme Rc ne sont pas Send car leur compteur de références n'est pas thread-safe. Ce trait est fondamental pour garantir la sécurité mémoire en contexte multi-thread."}},{"@type":"Question","name":"Quel est le rôle du trait Sync en Rust ?","acceptedAnswer":{"@type":"Answer","text":"Le trait Sync indique qu'un type peut être référencé en toute sécurité depuis plusieurs threads simultanément. Autrement dit, si T est Sync, alors &T est Send. Les types avec interior mutability non thread-safe comme RefCell ne sont pas Sync. Ce trait complète Send pour garantir la sécurité des accès concurrents aux données partagées."}},{"@type":"Question","name":"Que signifie mpsc dans le contexte des channels Rust ?","acceptedAnswer":{"@type":"Answer","text":"mpsc signifie Multiple Producer, Single Consumer. Ce type de channel permet à plusieurs threads d'envoyer des messages vers un unique thread récepteur. Le Sender peut être cloné pour obtenir plusieurs producteurs, mais il n'existe qu'un seul Receiver. C'est le pattern de communication inter-thread le plus courant dans la bibliothèque standard Rust."}},{"@type":"Question","name":"Comment créer un channel mpsc en Rust ?","acceptedAnswer":{"@type":"Answer","text":"La fonction mpsc::channel() retourne un tuple (Sender, Receiver). Le Sender est utilisé pour envoyer des messages avec send() et le Receiver pour les recevoir avec recv(). Cette fonction crée un channel asynchrone avec un buffer illimité. Pour un channel synchrone avec buffer limité, utiliser mpsc::sync_channel(n)."}},{"@type":"Question","name":"Que se passe-t-il quand on appelle recv() sur un Receiver dont tous les Sender ont été droppés ?","acceptedAnswer":{"@type":"Answer","text":"Quand tous les Sender associés à un channel ont été droppés, recv() retourne Err(RecvError). Cela signifie que le channel est fermé et qu'aucun nouveau message ne sera jamais envoyé. Ce mécanisme permet de détecter proprement la fin de la communication et de terminer les boucles de réception de manière élégante."}},{"@type":"Question","name":"Comment obtenir plusieurs producteurs (Sender) pour un même channel mpsc ?","acceptedAnswer":{"@type":"Answer","text":"Le Sender implémente le trait Clone, donc il suffit d'appeler clone() sur le Sender existant pour créer un nouveau producteur qui envoie vers le même channel. Chaque clone est indépendant et peut être déplacé vers un thread différent. Le channel reste ouvert tant qu'au moins un Sender existe."}},{"@type":"Question","name":"Pourquoi Rc n'est pas Send ni Sync ?","acceptedAnswer":{"@type":"Answer","text":"Rc utilise un compteur de références non-atomique pour des raisons de performance. Si Rc était partagé entre threads, plusieurs threads pourraient modifier le compteur simultanément, causant des data races et de la corruption mémoire. Pour le partage multi-thread, utiliser Arc qui utilise des opérations atomiques pour son compteur."}},{"@type":"Question","name":"Comment partager des données mutables en toute sécurité entre plusieurs threads ?","acceptedAnswer":{"@type":"Answer","text":"Pour partager des données mutables entre threads, utiliser Arc>. Arc permet le partage de propriété entre threads (Send + Sync), et Mutex assure l'exclusion mutuelle pour les modifications. Chaque thread doit acquérir le lock avec lock() avant de modifier les données, garantissant qu'un seul thread y accède à la fois."}},{"@type":"Question","name":"Quelle est la différence entre Mutex et RwLock ?","acceptedAnswer":{"@type":"Answer","text":"Mutex ne permet qu'un seul accès à la fois (lecture ou écriture). RwLock permet plusieurs lecteurs simultanés OU un seul écrivain exclusif. RwLock est plus performant quand les lectures sont fréquentes et les écritures rares, car les lecteurs ne se bloquent pas mutuellement. Cependant, RwLock a un overhead plus élevé que Mutex."}},{"@type":"Question","name":"Que se passe-t-il si un thread panic alors qu'il détient un Mutex lock ?","acceptedAnswer":{"@type":"Answer","text":"Quand un thread panic en détenant un lock, le Mutex est marqué comme empoisonné (poisoned). Les appels suivants à lock() retournent Err(PoisonError) contenant le guard. Cela permet de détecter que les données protégées peuvent être dans un état incohérent. Il est possible de récupérer le guard avec into_inner() si l'on souhaite continuer malgré le poison."}},{"@type":"Question","name":"Quelle est la différence entre mpsc::channel() et mpsc::sync_channel(n) ?","acceptedAnswer":{"@type":"Answer","text":"mpsc::channel() crée un channel asynchrone avec buffer illimité : send() retourne immédiatement sans bloquer. mpsc::sync_channel(n) crée un channel avec un buffer de taille n : send() bloque si le buffer est plein jusqu'à ce qu'un message soit consommé. Avec n=0, le channel est rendezvous : send() bloque jusqu'à ce que recv() soit appelé."}},{"@type":"Question","name":"Comment empêcher un deadlock lors de l'utilisation de plusieurs Mutex ?","acceptedAnswer":{"@type":"Answer","text":"Pour éviter les deadlocks, toujours acquérir les locks dans un ordre cohérent dans tout le programme. Si le thread A acquiert Mutex1 puis Mutex2, tous les threads doivent suivre le même ordre. Limiter la portée des locks au minimum nécessaire et éviter d'appeler du code externe en détenant un lock sont aussi des bonnes pratiques essentielles."}},{"@type":"Question","name":"Quelle méthode utiliser pour recevoir un message sans bloquer le thread ?","acceptedAnswer":{"@type":"Answer","text":"La méthode try_recv() sur le Receiver tente de recevoir un message sans bloquer. Elle retourne Ok(message) si un message est disponible, ou Err(TryRecvError::Empty) si le channel est vide, ou Err(TryRecvError::Disconnected) si tous les Sender ont été droppés. Cela permet de vérifier périodiquement les messages tout en faisant autre chose."}},{"@type":"Question","name":"Qu'est-ce qu'un data race et comment Rust les prévient-il ?","acceptedAnswer":{"@type":"Answer","text":"Un data race se produit quand plusieurs threads accèdent à la même mémoire simultanément, avec au moins un accès en écriture, sans synchronisation. Rust prévient les data races à la compilation grâce aux traits Send et Sync et au système de ownership/borrowing. Le compilateur refuse tout code qui pourrait causer un data race, garantissant la thread safety sans runtime overhead."}},{"@type":"Question","name":"Comment utiliser thread::scope pour éviter le mot-clé move ?","acceptedAnswer":{"@type":"Answer","text":"thread::scope crée une portée dans laquelle les threads peuvent emprunter des données du scope parent. Les threads spawnés dans ce scope sont garantis de terminer avant la fin du scope, donc le compilateur peut prouver que les emprunts sont valides. Cela évite de devoir cloner ou utiliser Arc pour partager des données en lecture seule avec des threads temporaires."}},{"@type":"Question","name":"Quel type utiliser pour un compteur atomique partagé entre threads ?","acceptedAnswer":{"@type":"Answer","text":"Pour un compteur atomique, utiliser AtomicUsize (ou AtomicI32, AtomicU64, etc.) du module std::sync::atomic. Ces types fournissent des opérations atomiques comme fetch_add() et load() sans nécessiter de Mutex. Ils sont plus performants qu'un Mutex pour des opérations simples sur des valeurs primitives car ils utilisent des instructions CPU atomiques directement."}},{"@type":"Question","name":"Quel est l'impact de l'Ordering dans les opérations atomiques ?","acceptedAnswer":{"@type":"Answer","text":"L'Ordering spécifie les garanties de synchronisation mémoire. Relaxed offre uniquement l'atomicité sans garantie d'ordre. Acquire/Release créent une synchronisation point-à-point entre threads. SeqCst (Sequentially Consistent) garantit un ordre total observable par tous les threads. Choisir le bon Ordering est crucial pour la performance tout en maintenant la correction du programme concurrent."}}]}