Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Strengthen the memory ordering order on that refcounting to work around a bug
authorMartin Quinson <martin.quinson@loria.fr>
Wed, 26 Apr 2017 14:50:57 +0000 (16:50 +0200)
committerMartin Quinson <martin.quinson@loria.fr>
Wed, 26 Apr 2017 14:51:53 +0000 (16:51 +0200)
src/simix/ActorImpl.hpp

index 3e0f707..e1ffbda 100644 (file)
@@ -73,13 +73,17 @@ private:
 public:
   friend void intrusive_ptr_add_ref(ActorImpl* process)
   {
-    process->refcount_.fetch_add(1, std::memory_order_relaxed);
+    // std::memory_order_relaxed ought to be enough here instead of std::memory_order_seq_cst
+    // But then, we have a threading issue when an actor commits a suicide:
+    //  it seems that in this case, the worker thread kills the last occurrence of the actor
+    //  while usually, the maestro does so. FIXME: we should change how actors suicide
+    process->refcount_.fetch_add(1, std::memory_order_seq_cst);
   }
   friend void intrusive_ptr_release(ActorImpl* process)
   {
     // inspired from http://www.boost.org/doc/libs/1_55_0/doc/html/atomic/usage_examples.html
     if (process->refcount_.fetch_sub(1, std::memory_order_release) == 1) {
-      // Make sure that any changes done on other threads before their acquire are commited before our delete
+      // Make sure that any changes done on other threads before their acquire are committed before our delete
       // http://stackoverflow.com/questions/27751025/why-is-an-acquire-barrier-needed-before-deleting-the-data-in-an-atomically-refer
       std::atomic_thread_fence(std::memory_order_acquire);
       delete process;