1

I have a processing loop on the host, where I record an event in a GPU stream. Then another stream waits for that event (waits for event's state "set" or "true"). Will this function (cudaStreamWaitEvent) unset this event (so, switching it to "unset" or "false")? If not, what CUDA function I can use to unset this event?

einpoklum
  • 118,144
  • 57
  • 340
  • 684
psihodelia
  • 29,566
  • 35
  • 108
  • 157

1 Answers1

2

This sounds very much like an XY question. You might be better off describing at a higher level what it is you are trying to accomplish, or what problem you are facing or think you are facing.

cudaStreamWaitEvent does not "unset" an event.

When the event is encountered in the stream, then cudaStreamWaitEvent will unblock, and any subsequent calls to cudaStreamWaitEvent on the same event will immediately unblock (assuming no cudaEventRecord has again been issued for that event). This behavior is easy to prove with a trivial code sample.

The function that "unsets" a cudaEvent is cudaEventRecord(). Any cudaStreamWaitEvent calls issued after that event gets recorded will wait again, until it is encountered again.

You may want to read the runtime API documentation for cudaEventRecord and cudaStreamWaitEvent. Note the following excerpts:

cudaEventRecord:

If cudaEventRecord() has previously been called on event, then this call will overwrite any existing state in event. Any subsequent calls which examine the status of event will only examine the completion of this most recent call to cudaEventRecord().

cudaStreamWaitEvent:

The stream stream will wait only for the completion of the most recent host call to cudaEventRecord() on event.

Community
  • 1
  • 1
Robert Crovella
  • 143,785
  • 11
  • 213
  • 257
  • Thank you! If a cudaEventRecord of the same event has again been issued while other cudaStreamWaitEvent are waiting for a previous cudaEventRecord, then they will wait for the last one event record? – psihodelia Aug 15 '15 at 19:36
  • Another question: "and any subsequent calls to cudaStreamWaitEvent on the same event will immediately unblock" - it applies for all streams, including other contexts? – psihodelia Aug 15 '15 at 19:39
  • Regarding your second additional question, the statement applies for any valid usage of an event with respect to streams, contexts, and devices. – Robert Crovella Aug 15 '15 at 19:47
  • Regarding your first additional question, if the second call to `cudaEventRecord` occurs before the event in question actually occurs, then the second call simply overwrites the first -- refer to my edited answer. Then anything waiting will wait on the second issuance. If the second call to `cudaEventRecord` occurs *after* the event in question actually occurs, then I think your question doesn't apply, because all previous `cudaStreamWaitEvent` calls would unblock at the moment the event occurred (prior to the second issuance of `cudaEventRecord` on that event). – Robert Crovella Aug 15 '15 at 20:03
  • It is really difficult to understand a cross-context stream syncs because visual profiler is not showing events and cudaStreamWaitEvent blocking points in separate streams. What I understand now is following: an event can be moved to the right (in visual profiler) by a next recording of it; cudaStreamWaitEvent in different contexts do not depend on each other. – psihodelia Aug 15 '15 at 20:10
  • Docs are not very good. It would be simpler to understand event+stream handling if it could be explained in standard CS terms algorithmically, e.g. Stream is FIFO, how event's and a blocking point (Wait) positions are related to this FIFOs (multi-streams), etc. – psihodelia Aug 15 '15 at 20:15
  • I agree, the docs are never good enough. I mentioned the docs because it sure seemed to me like the question you were asking (the first one in the comments) was answered there, suggesting to me you hadn't read them. – Robert Crovella Aug 15 '15 at 20:42