Events: connect streams without blocking the entire device

Submit the producer in S1, record event E in S1 after it, and submit a wait for that recorded event in S2 before the consumer. Work in S2 after the wait cannot proceed past the required event completion until the captured producer boundary is reached. The event does not automatically include later work added after its record. Place the record too early and the consumer can race with the actual producer; place the wait after the consumer and it cannot retroactively fix the read.

cudaStreamWaitEvent creates a stream dependency without making the CPU wait for all device work. cudaEventSynchronize instead blocks the host until the event’s captured work is complete, and cudaEventQuery lets the host ask whether it is complete. A not-ready result is not a failure of the kernel by itself. Check API return values and create an acyclic dependency graph. An event that has never been recorded represents no captured work, so waiting on it does not wait for a future record. Do not use an unrecorded placeholder as a barrier.

An event object can be recorded again, so a reusable pipeline must ensure each wait refers to the intended captured record according to the API’s most-recent-record semantics at submission. Give each buffer slot an explicit lifecycle: input available, producer complete, consumer complete, then reuse permitted. Reusing one event carelessly across multiple in-flight iterations can associate a wait with the wrong boundary. Separate event objects per pipeline slot or another proven protocol can make that lifecycle easier to reason about.

The completion that protects a buffer depends on its last relevant user. A producer-ready event allows a consumer to begin; it does not allow the host to overwrite the buffer while the consumer still reads it. Record or observe a consumer-complete boundary before reuse. The same principle applies to asynchronous copies and deallocation: launch order is not a lifetime proof unless the deallocation or overwrite is correctly ordered after every use under the actual API semantics.

For a simple timing experiment, record a start event and an end event around the intended work in a suitable stream and wait for completion before reading elapsed time. Timing-enabled events are required for elapsed-time queries. Other work, contention, and placement can influence what is measured, so do not equate an event interval with an isolated instruction cost. A CPU timer around cudaEventRecord calls measures a different interval unless it also accounts for device completion.

The network lab shows a fixed data-dependency graph, not asynchronous execution. Reset, set x=2 and w=1, predict sigmoid(1.5)≈0.818, then Step. The output mathematically depends on the earlier multiplication, but the graph has no streams, records, waits, or event generations. Use that limited graph to name the producer and consumer, then add the actual event edge in a separate schedule. Changing a number in the lab cannot validate a real buffer-lifetime protocol.