gianm commented on a change in pull request #8236: Add TaskResourceCleaner; fix 
a couple of concurrency bugs in batch tasks
URL: https://github.com/apache/incubator-druid/pull/8236#discussion_r311792976
 
 

 ##########
 File path: 
indexing-service/src/main/java/org/apache/druid/indexing/common/task/CompactionTask.java
 ##########
 @@ -146,10 +146,13 @@
   private final RetryPolicyFactory retryPolicyFactory;
 
   @JsonIgnore
-  private List<IndexTask> indexTaskSpecs;
+  private final AppenderatorsManager appenderatorsManager;
 
   @JsonIgnore
-  private AppenderatorsManager appenderatorsManager;
+  private List<IndexTask> indexTaskSpecs;
+
+  @Nullable
+  private volatile IndexTask currentRunningTaskSpec = null;
 
 Review comment:
   > Unfortunately, in reality, what we have is "volatile = high probability 
that there are some concurrency defects around the code".
   
   Interesting point. I wonder if we can nail down what usages of volatile are 
especially likely to be buggy. My intuitions would be:
   
   - Not very risky: 'one-way' volatiles that are used to ensure safe 
publishing out of an 'owner' thread, but where the 'non-owner' threads aren't 
intended to call any mutation methods on the published object. This kind of 
pattern is sometimes used for publishing objects that monitoring or 
status-checking code will periodically inspect.
   - Not very risky: volatiles used for deferred initialization (updated once 
from null -> nonnull, but not updated ever again).
   - More risky: designs where a reference is updated multiple times by an 
'owner' thread, and 'non-owner' threads may call some mutation methods on the 
object.
   - Even more risky: designs where there is no clear 'owner' thread.
   
   (The original example of `currentRunningTaskSpec` would have seemed risky by 
the above intuitions: there is a clear owner thread, but the reference is 
updated more than once, and non-owners are going to be calling mutation methods)

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to