From 1e76d51c41234db9701ca3017df4edf922ba4ec2 Mon Sep 17 00:00:00 2001 From: Hayodea Hekol Date: Thu, 27 Nov 2025 22:29:05 -0400 Subject: [PATCH] Todo: Update By solving the issues in finalize() for IoUringAssmEngn and OClCollMeshEngn, we've solved this as a side-effect. --- todo | 36 ------------------------------------ 1 file changed, 36 deletions(-) diff --git a/todo b/todo index 239c1bf..fd2993c 100644 --- a/todo +++ b/todo @@ -35,39 +35,3 @@ have unified memory with the host cpu complex. This causes the kernels to overrun their timelices and triggers repeated timeslice deferrals. - - PcloudStimProducer::stop=>start() sequence: - - Attaching and detaching StimBuffs from StimProducers: -We've written code recently to attach and detact stimBuffs from a -stimProducer. The code is quite nice, but there's this hanging -omen over the fact that we put no thought into ensuring that -detachment doesn't cause an in-flight async production op to -access invalid data. - -The in-flight async production ops use the SpMcRingbuffs that -inhabit the stimbuffs. If we don't ensure that all in-flight -async ops are retired before we detach a stimbuff from a -producer, we could end up with the producer writing data into -memory which has been reclaimed and repurposed. -Similarly, if we're not careful about the order in which we -assign the stimBuff pointers during attachment, we could -potentially cause producers to see a partially initialized -StimBuff object. - -I think this can be solved without locking/synchronization -by being very careful to ensure that by the time that -StimProducer::stop() exits, all in-flight production -operations are reasonably sure to be halted. If all -in-flight operations are halted; and if production ops -cannot be launched while a StimBuff is being attached/ -detached, this means we don't have to worry about accesses -to stale StimBuff instance state; or access to partially -initialized StimBuff instance state. - -So this problem is solved by dealing with the in-flight -cancelation problem described above, concerning -[IoUringAssmEngn|OClCollMeshEngn]::start/stop(), and -StimulusBuffer::start/stop(), and ensuring that after -stop() has returned, we can be reasonably sure that all -in-flight ops have exited.