Question

in trying to improve my understanding on concurrency issues, I am looking at the following scenario (Edit: I’ve changed the example from List to Runtime, which is closer to what I am trying):

public class Example {
    private final Object lock = new Object();
    private final Runtime runtime = Runtime.getRuntime();
    public void add(Object o) { 
        synchronized (lock) { runtime.exec(program + " -add "+o); } 
    }
    public Object[] getAll() { 
        synchronized (lock) { return runtime.exec(program + " -list "); }
    }
    public void remove(Object o) { 
        synchronized (lock) { runtime.exec(program + " -remove "+o); } 
    }
}

As it stands, each method is by thread safe when used standalone. Now, what I’m trying to figure out is how to handle where the calling class wishes to call:

for (Object o : example.getAll()) {
    // problems if multiple threads perform this operation concurrently
    example.remove(b); 
}

But as noted, there is no guarantee that the state will be consistent between the call to getAll() and the calls to remove(). If multiple threads call this, I’ll be in trouble. So my question is – How should I enable the developer to perform the operation in a thread safe manner? Ideally I wish to enforce the thread safety in a way that makes it difficult for the developer to avoid/miss, but at the same time not complicated to achieve. I can think of three options so far:

A: Make the lock ‘this’, so the synchronization object is accessible to calling code, which can then wrap the code blocks. Drawback: Hard to enforce at compile time:

synchronized (example) {
    for (Object o : example.getAll()) {
        example.remove(b);
    }
}

B: Place the combined code into the Example class – and benefit from being able to optimize the implementation, as in this case. Drawback: Pain to add extensions, and potential mixing unrelated logic:

public class Example {
   ...
   public void removeAll() { 
       synchronized (lock) { Runtime.exec(program + " -clear"); } 
   }
}

C: Provide a Closure class. Drawback: Excess code, potentially too generous of a synchronization block, could in fact make deadlocks easier:

public interface ExampleClosure {
    public void execute(Example example);
}
public Class Example {
    ...
    public void execute(ExampleClosure closure) { 
        synchronized (this) { closure.execute(this); } 
    }
}

example.execute(new ExampleClosure() {
        public void execute(Example example) { 
            for (Object o : example.getAll()) {
                example.remove(b);
            }
        }
    }
);

Is there something I’m missing? How should synchronization be scoped to ensure the code is thread safe?

Answer 1

I think everyone is missing his real problem. When iterating over the new array of Object’s and trying to remove one at a time the problem is still technically unsafe (though ArrayList implantation would not explode, it just wouldnt have expected results).

Even with CopyOnWriteArrayList there is the possibility that there is an out of date read on the current list to when you are trying to remove.

The two suggestions you offered are fine (A and B). My general suggestion is B. Making a collection thread-safe is very difficult. A good way to do it is to give the client as little functionality as possible (within reason). So offering the removeAll method and removing the getAll method would suffice.

Now you can at the same time say, ‘well I want to keep the API the way it is and let the client worry about additional thread-safety’. If thats the case, document thread-safety. Document the fact that a ‘lookup and modify’ action is both non atomic and non thread-safe.

Today’s concurrent list implementations are all thread safe for the single functions that are offered (get, remove add are all thread safe). Compound functions are not though and the best that could be done is documenting how to make them thread safe.