huajsj commented on a change in pull request #10234:
URL: https://github.com/apache/tvm/pull/10234#discussion_r812441417



##########
File path: src/runtime/pipeline/pipeline_struct.h
##########
@@ -42,6 +52,75 @@ using GlobalOutputPair = std::pair<int, int>;
  * The first 'int' is the module index, and the second 'int' is the module 
output index.
  */
 using ModuleOutputPair = std::pair<int, int>;
+/*!
+ *\brief The pair includes the module index and the module input index.
+ * The first 'int' is the module index, and the second 'int' is the module 
input index.
+ */
+using ModuleInputPair = std::pair<int, int>;
+/*!\brief The data notification structure.*/
+class DataNotify {
+ private:
+  /*!\brief The 'contitional variable' is used to wait for notification.*/
+  std::condition_variable condition_;
+  /*!\brief The mutex is used to protect the 'conditional variable'.*/
+  std::mutex mutex_;
+  /*!\brief Whether a data is ready or not.*/
+  volatile bool data_ready_ = false;
+  /*!\brief Whether the thread should exit or not.*/
+  volatile bool exit_state_ = false;

Review comment:
       I agree with that volatile is bad practice for 'atomic' guarantee, but 
in our case we only need to guarantee the data 'visibility' under multiple 
thread mode ,  for such requirement volatile should be ok.
   
   about 'atomic' guarantee part, for vairable 'data_ready_' the existing 
'mutex_' and conditional variable will help for the atomic guarantee,   for 
variable exit_state_, because each notification only have one parent and one 
child, under such single consumer and single producer scenario the both reading 
and writing of 'exit_state' are native atomic then no need  additional 
protection.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to