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

documentation: sync copy is using the default stream #59

Open
vmx opened this issue Sep 2, 2021 · 0 comments
Open

documentation: sync copy is using the default stream #59

vmx opened this issue Sep 2, 2021 · 0 comments

Comments

@vmx
Copy link
Contributor

vmx commented Sep 2, 2021

I'm new to CUDA and I ran into a race condition which could perhaps be prevented with changes to the documentation.

The problem

Mixing the default stream and a custom stream isn't a good idea.

The implementations of the CopyDestination trait are implicitly using the default stream. When you launch a kernel on a stream that was created with the NON_BLOCKING flag, this can lead to a race condition.

My confusion

The documentation of the NON_BLOCKING stream flag has a good explanation about the default (NULL) stream. Though the sentence:

Since RustaCUDA does not provide access to the NULL stream, this flag has no effect in
most circumstances. However, it is recommended to use it anyway, as some other crate
in this binary may be using the NULL stream directly.

made me believe that as long as I use RustaCUDA, I should enable NON_BLOCKING and everything will be fine. The default stream is not used within the library, which is not true as mentioned above.

For me there were two solutions:

  1. Either not setting the NON_BLOCKING stream flag, this way even if I launch the kernel on a custom stream (there is currently no way in RustaCUDA to launch it on the default stream), things would properly be synchronized.
  2. I use the async copy methods on the same stream I launch the kernel on and synchronize the stream right after the copy operation (that's what I did).

Proposed fix

I propose adding a warning/info to the NON_BLOCKING stream flag documentation, that states that the synchronuous copy versions use the default stream and this setting might have an impact. Additionally I'd add information about the default stream to the CopyDestination trait itself.

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