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.

Sign up for GitHub

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

Jump to bottom

promise/future deadlock #25066

Open
K-ballo opened this issue Sep 3, 2015 · 4 comments
Open

promise/future deadlock #25066

K-ballo opened this issue Sep 3, 2015 · 4 comments
Labels
bugzilla Issues migrated from bugzilla confirmed Verified by a second party libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi. threading issues related to threading

Comments

@K-ballo
Copy link

K-ballo commented Sep 3, 2015

Bugzilla Link 24692
Version unspecified
OS All
CC @mclow

Extended Description

The following test case results in a deadlock:

#include <chrono>
#include <future>
#include <iostream>
#include <utility>

template <typename T>
struct weird {
  std::future<weird<T>> f;

  explicit weird(std::future<weird<T>> f) : f(std::move(f)) {}

  weird(weird&& other)
    : f(std::move(other.f))
  {
    if (f.wait_for(std::chrono::seconds(1)) == std::future_status::timeout) {
      std::cout << "Moving but the future is not ready yet\n";
    }
  }
};

int main() {
  std::promise<weird<int>> p;
  weird<int> w(p.get_future());
  p.set_value(std::move(w));
}

This is caused by executing arbitrary user code under a lock.
@llvmbot
Copy link
Collaborator

llvmbot commented Sep 5, 2015

Yikes... Thanks for the report.

@llvmbot
Copy link
Collaborator

llvmbot commented Sep 5, 2015

@​K-Ballo. Do you think that this code should actually work? It seems to me that this is likely non-standard.

@K-ballo
Copy link
Author

K-ballo commented Sep 7, 2015

@​K-Ballo. Do you think that this code should actually work? It seems to me
that this is likely non-standard.

Yes, I think this code is required to actually work. What makes you think this is non-standard?

@llvmbot
Copy link
Collaborator

llvmbot commented Sep 8, 2015

I think the only possible way to fix this (without breaking the ABI) is to:

  1. Release the lock while constructing the value.
  2. Use the top bits of the __state_ variable to implement a "construction lock" that will allow us to serialize multiple calls to "set_value(...)"

I'm not yet sure if this is going to work. I think it's likely that these changes aren't going to play nice with older versions of libc++.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
@llvmbot llvmbot added the confirmed Verified by a second party label Jan 26, 2022
@philnik777 philnik777 added the threading issues related to threading label Jul 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla confirmed Verified by a second party libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi. threading issues related to threading
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@K-ballo @philnik777 @llvmbot