Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potential race condition in BaseOperationImpl.java #43

Open
MusaTalluzi opened this issue Oct 15, 2024 · 0 comments
Open

Potential race condition in BaseOperationImpl.java #43

MusaTalluzi opened this issue Oct 15, 2024 · 0 comments

Comments

@MusaTalluzi
Copy link

MusaTalluzi commented Oct 15, 2024

Our profiler shows BaseOperationImpl.isCancelled spends 90% of the time in blocked state and we suspect it's causing deadlocks since it shares the same lock with other operations in the Operation class:

  public final synchronized boolean isCancelled() {
    return cancelled;
  }

  public final synchronized void cancel() {
    cancelled = true;

    synchronized (clones) {
      Iterator<Operation> i = clones.iterator();
      while(i.hasNext()) {
        i.next().cancel();
      }
    }

    wasCancelled();
    callback.receivedStatus(CANCELLED);
    callback.complete();
  }

If the operation is cloned (original X, clone Y) and two threads call cancel():

  • Thread A calls X.cancel(), aquires X's lock and yields
  • Thread B calls Y.cancel(), aquires Y's lock, enters synchronized block, i.next() returns X, thread blocks on i.next().cancel() since thread A is already executing that function
  • Thread A resumes execution, its i.next() returns A and it blocks similar to B

Is this a valid situation that could happen?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant