[GitHub] [nifi-minifi-cpp] szaszm commented on a change in pull request #746: MINIFICPP-1185 - Remove moodycamel::concurrentqueue from threadpool

[GitBox <gi...@apache.org>]

szaszm commented on a change in pull request #746: MINIFICPP-1185 - Remove moodycamel::concurrentqueue from threadpool
URL: https://github.com/apache/nifi-minifi-cpp/pull/746#discussion_r396515674
 
 

 ##########
 File path: libminifi/include/utils/ConcurrentQueue.h
 ##########
 @@ -0,0 +1,155 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *     http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+#ifndef LIBMINIFI_INCLUDE_CONCURRENT_QUEUE_H
+#define LIBMINIFI_INCLUDE_CONCURRENT_QUEUE_H
+
+#include <deque>
+#include <mutex>
+#include <condition_variable>
+
+namespace org {
+namespace apache {
+namespace nifi {
+namespace minifi {
+namespace utils {
+
+template <typename T>
+class ConcurrentQueue {
+ public:    
+  ConcurrentQueue() = default;
+  virtual ~ConcurrentQueue() = default;
+
+  ConcurrentQueue(const ConcurrentQueue& other) = delete;
+  ConcurrentQueue& operator=(const ConcurrentQueue& other) = delete;
+  ConcurrentQueue(ConcurrentQueue&& other)
+    : ConcurrentQueue(std::move(other), std::lock_guard<std::mutex>(other.mutex_)) {}
+
+  ConcurrentQueue& operator=(ConcurrentQueue&& other) {
+    if (this != &other) {
+      std::lock(mtx_, other.mtx_);
+      std::lock_guard<std::mutex> lk1(mtx_, std::adopt_lock);
+      std::lock_guard<std::mutex> lk2(other.mtx_, std::adopt_lock);
+      queue_.swap(other.queue_);
+    }
+    return *this;
+  }
+
+  virtual bool tryDequeue(T& out) {
+    std::unique_lock<std::mutex> lck(mtx_);
+    return tryDequeue(lck, out);
+  }
+
+  virtual bool empty() const {
+    std::lock_guard<std::mutex> guard(mtx_);
+    return queue_.empty();
+  }
+
+  virtual size_t size() const {
+    std::lock_guard<std::mutex> guard(mtx_);
+    return queue_.size();
+  }
+
+  virtual void clear() {
+    std::lock_guard<std::mutex> guard(mtx_);
+    queue_.clear();
+  }
+
+  template <typename... Args>
+  void enqueue(Args&&... args) {
+    std::lock_guard<std::mutex> guard(mtx_);
+    queue_.emplace_back(std::forward<Args>(args)...);
+  }
+
+ private:
+   ConcurrentQueue(ConcurrentQueue&& other, std::lock_guard<std::mutex>&)
+    : queue_( std::move(other.queue_) ) {}
+
+ protected:
+  bool tryDequeue(std::unique_lock<std::mutex>& lck, T& out) {
+    if (!lck.owns_lock()) {
+      return false;
+    }
+    if (queue_.empty()) {
+      return false;
+    }
+    out = std::move(queue_.front());
+    queue_.pop_front();
+    return true;
+  }
+  std::deque<T> queue_;
+  mutable std::mutex mtx_;
+};
+
+template <typename T>
+class ConditionConcurrentQueue : public ConcurrentQueue<T> {
 
 Review comment:
   I think it's not a good design to allow dynamic polymorphism between these containers, despite the "is a" relationship being present. My intuition screams design issue but can't fully grasp what is the root cause. I'll try to make some points below.
   
   Performance: I prefer not to have virtual functions on containers, as most or all users will know their requirements against their container. This design violates the zero overhead principle by imposing virtual calls on users that don't need notification capabilities.
   
   Hierarchy: I think the relationship here is an added [aspect](https://en.wikipedia.org/wiki/Aspect-oriented_programming) rather than a hierarchy.
   http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c120-use-class-hierarchies-to-represent-concepts-with-inherent-hierarchical-structure-only
   
   Inheritance: 
   - The inheritance here is both interface and implementation inheritance.
   http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c129-when-designing-a-class-hierarchy-distinguish-between-implementation-inheritance-and-interface-inheritance
   - Leaving the class open for extension makes it possible for subclasses to violate the invariants of the base class, violating encapsulation.
   
   Do we really need runtime polymorphism? If yes, I'd make it possible through concept-based polymorphism (via type erasure) without affecting the implementation.
   
   In either case, I'd make ConcurrentQueue closed and ConditionConcurrentQueue a wrapper around ConcurrentQueue ("implemented in terms of") rather than a public subclass ("is a"). To access the mutex, I recommend this to be a private inheritance with only the mutex of the base class marked as protected, or some other way of leaking the mutex.
   
   I feel like my above arguments are weak, and my proposed design is not very sound. As always, I welcome discussion.

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services