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

Fix std::future status query #596

Open
wants to merge 6 commits into
base: branch-25.04
Choose a base branch
from

Conversation

kingcrimsontianyu
Copy link
Contributor

@kingcrimsontianyu kingcrimsontianyu commented Jan 26, 2025

Pending performance regression check!!

This PR fixes the std::future status query according to the discussion in #593 .

  • The future objects of parallel I/O operations are no longer created using std::async with the deferred launch policy. Doing so would cause the future status to be falsely reported as done. Instead, as suggested, they are created by the underlying thread pool (more specifically by the promise objects). This enables non-blocking future status query.
  • The trivial I/O cases that do not involve task splitting are now performed in a synchronous, blocking way as suggested, instead of being evaluated lazily via std::async with the deferred launch policy.

@kingcrimsontianyu kingcrimsontianyu added bug Something isn't working non-breaking Introduces a non-breaking change c++ Affects the C++ API of KvikIO labels Jan 26, 2025
@kingcrimsontianyu kingcrimsontianyu self-assigned this Jan 26, 2025
Copy link

copy-pr-bot bot commented Jan 26, 2025

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

@kingcrimsontianyu
Copy link
Contributor Author

/ok to test

1 similar comment
@kingcrimsontianyu
Copy link
Contributor Author

/ok to test

@kingcrimsontianyu
Copy link
Contributor Author

/ok to test

@vyasr
Copy link
Contributor

vyasr commented Jan 27, 2025

Discussing further in #593 rather than here.

@kingcrimsontianyu kingcrimsontianyu changed the title Take deferred std::future into account for status query [Experimental] Take deferred std::future into account for status query Jan 27, 2025
@kingcrimsontianyu kingcrimsontianyu changed the base branch from branch-25.02 to branch-25.04 January 29, 2025 05:42
@kingcrimsontianyu
Copy link
Contributor Author

/ok to test

@kingcrimsontianyu kingcrimsontianyu changed the title [Experimental] Take deferred std::future into account for status query [Experimental] Fix std::future status query Jan 29, 2025
@kingcrimsontianyu kingcrimsontianyu added breaking Introduces a breaking change and removed non-breaking Introduces a non-breaking change labels Jan 29, 2025
@kingcrimsontianyu
Copy link
Contributor Author

/ok to test

1 similar comment
@kingcrimsontianyu
Copy link
Contributor Author

/ok to test

@kingcrimsontianyu kingcrimsontianyu added non-breaking Introduces a non-breaking change and removed breaking Introduces a breaking change labels Jan 30, 2025
Copy link
Member

@madsbk madsbk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good @kingcrimsontianyu. The only question is if the overhead of creating the extra gather task is an issue. I suspect not, but it would be good to get it confirmed.

cc. @GregoryKimball, @vuule.

/**
* @brief Submit the move-only task callable to the underlying thread pool.
*
* @tparam F Callable type. F shall be move-only and have no argument.
Copy link
Contributor Author

@kingcrimsontianyu kingcrimsontianyu Jan 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is tempting to add the "can't copy" part to the code to improve type safety:

template <typename F, std::enable_if_t<!std::is_copy_constructible_v<F>, bool> = true>
std::future<std::size_t> submit_move_only_task(F op_move_only)

But this does not work.
For the non-copyable gather_tasks below, trying to copy construct results in compile error, but the type trait gives unexpected result.

auto gather_tasks_copy = gather_tasks; // Compile error as expected
static_assert(std::is_copy_constructible_v<decltype(gather_tasks)>); // No compile error. Surprise.

A simpler example:

std::vector<std::future<int>> move_only;
static_assert(std::is_copy_constructible_v<decltype(move_only)>); // No compile error. Surprise.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kingcrimsontianyu kingcrimsontianyu force-pushed the improve-future-query branch 2 times, most recently from 41afba6 to 94c266e Compare February 1, 2025 03:27
@vyasr
Copy link
Contributor

vyasr commented Feb 4, 2025

I think this looks good overall to me now. Is it ready for a thorough review? I'm not sure if it is intentionally still in draft or not.

@kingcrimsontianyu kingcrimsontianyu changed the title [Experimental] Fix std::future status query Fix std::future status query Feb 4, 2025
@kingcrimsontianyu
Copy link
Contributor Author

Thanks for the reminder. Other than pending performance assessment, this PR should be ready for review.

@kingcrimsontianyu kingcrimsontianyu marked this pull request as ready for review February 4, 2025 15:56
@kingcrimsontianyu kingcrimsontianyu requested a review from a team as a code owner February 4, 2025 15:56
@kingcrimsontianyu
Copy link
Contributor Author

I'll use cuDF bench for performance assessment, and post the results here when ready.

Copy link
Contributor

@vyasr vyasr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I'll leave it to you to verify performance before merging.

@@ -152,6 +153,7 @@ std::tuple<void*, std::size_t, std::size_t> get_alloc_info(void const* devPtr,
template <typename T>
bool is_future_done(T const& future)
{
assert(future.valid());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is a public API, do we want to throw if this condition is violated or are we happy with a debug assertion?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I think we do need to check the pre-condition to avoid UB. Done.

return detail::posix_device_read(_fd_direct_off, buf, size, file_offset, 0);
};
return std::async(std::launch::deferred, task);
PushAndPopContext c(ctx);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add a note that this execution model provides API compatibility with the rest of the future-based APIs in the library while also ensuring that the future is actually immediately available since we don't want this call to be asynchronous.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Done.
I realized that the C++ concurrency TS has a utility function meant to do the exact same thing, so I put a simplistic implementation there in utils.hpp:

std::future<std::decay_t<T>> make_ready_future(T&& t)

/**
* @brief Submit the move-only task callable to the underlying thread pool.
*
* @tparam F Callable type. F shall be move-only and have no argument.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working c++ Affects the C++ API of KvikIO non-breaking Introduces a non-breaking change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants