From d2276c3c9b16fd46a3912ab8d58c418e67d8ce3e Mon Sep 17 00:00:00 2001 From: Stephen Connolly Date: Wed, 21 Oct 2015 10:01:49 +0100 Subject: [PATCH] [JENKINS-31055] Note theoretical race condtion Seems rather unlikely, but none the less it is a possibility. Not sure how we should handle this though: * We do not want to hold the Queue lock while performing I/O as that will grind everything to a halt * We do not want a big fat lock on all nodes * If we have a per-node lock then the save everything method may have to grab them all In short, it gets ugly real fast. For now, I believe that the risk is very low as releasing a lock does not intrinsically deschedule a currently running thread so the likely course of events is that the thread will release the lock and at least start the save before a competing thread could acquire the lock update remove the node release the lock and delete the node's directory --- core/src/main/java/jenkins/model/Nodes.java | 2 ++ 1 file changed, 2 insertions(+) diff --git a/core/src/main/java/jenkins/model/Nodes.java b/core/src/main/java/jenkins/model/Nodes.java index 342e2a5ba9..9c199a6b1d 100644 --- a/core/src/main/java/jenkins/model/Nodes.java +++ b/core/src/main/java/jenkins/model/Nodes.java @@ -138,6 +138,7 @@ public class Nodes implements Saveable { jenkins.trimLabels(); } }); + // TODO there is a theoretical race whereby the node instance is updated/removed after lock release persistNode(node); } } @@ -191,6 +192,7 @@ public class Nodes implements Saveable { exists = false; } if (exists) { + // TODO there is a theoretical race whereby the node instance is updated/removed after lock release persistNode(node); return true; } -- GitLab