Nous avons tous l'habitude de jobs multiples actifs en même temps. La différence est que les threads sont étroitement couplés, tandis que que les jobs sont le plus souvent isolés les uns des autres. Ces derniers ne peuvent communiquer entre eux que par des objets externes du
Threads multiples vs. jobs multiples
genre files d’attente de données ou de messages. Les threads communiquent entre eux par défaut, parce qu’ils s’exécutent dans le même job, et parfois même dans le même programme avec les mêmes variables de programmes. La difficulté avec les threads consiste à limiter leur communication et à ne les autoriser qu’en mode thread-safe (c’est-à-dire en toute sécurité quant aux threads et à leurs actions).
Sécurité des threads
La sécurité des threads devient critique quand un job en a plusieurs. Pour que votre application soit vraiment thread-safe, il faut que les programmes ou les procédures qu’elle appelle le soient eux-mêmes et n’utilisent que des commandes qui le soient elles aussi. Si votre application utilise des ressources partagées, elle doit aussi assurer la sécurité des threads. Les exemples de ressources partageables sont nombreux : espaces utilisateur, stockage statique, stockage dont l’accès se fait par un pointeur de base, et fichiers remplacés à partager.
Téléchargez cette ressource
Guide de Cyber-résilience pour Microsoft 365
La violation de votre tenant M365 va au-delà d’un simple incident de cybersécurité. Elle peut entraîner une interruption opérationnelle généralisée, des perturbations commerciales et une exposition de vos données sensibles. Découvrez les méthodes et technologies pour évaluer, comparer et renforcer votre posture de sécurité Microsoft 365.
Les articles les plus consultés
A travers cette chaîne
A travers ITPro
