本来我想设计一个ThreadManager要存储的类 threads连同 data type objects和 function type objects他们将与之合作。该类负责管理标准多线程库中关联类型的内存、访问、传输、释放、锁定、解锁、连接和其他典型的通用功能。它最初旨在将包含线程及其 ID 与特定线程有权访问的一组特定资源相关联。

阅读完 cppreference 上的文档后关于mutex , shared_mutex , lock_guard , shared_lock , std::function<...>等，现在知道 mutexes和 lock_guards是不可复制的，而且如果我将类模板化以存储任意 function objects 的事实, function pointers , lambdas或 std::function<>作为 std::function<>在这个类的容器中，这个预期的单例的类实例化只能存储一个特定的函数签名，限制它不能实例化任何其他声明签名。

关于 mutexes 的标准库中多线程库的这些行为和属性, shared_mutexes lock_guards , threads , promises , futures等等...我想到了我对这门课的整体设计考虑过多。

您可以通过我之前提出的这个问题来引用我最初的设计尝试。 Storing arbitrary function objects into a class member container without knowing their declaration signature , 这应该让您了解我正在尝试做什么。

更多地了解它们的行为、属性和职责 我想知道以下内容是否适合预期的设计过程。

而不是存储任何 mutexes , lock_guards , threads , data type objects或 function objects ;只存储生成的 ids 是否更有意义？的 threads ，让我的经理类更像是一个监控、记录和报告类型的类？

我的新意图是容器将线程的 ID 作为其键与关联的公共(public)结构一起存储在关联的映射中。该结构将包含组合资源的所有职责和操作的属性列表。这可能允许支持以下某些功能:优先级队列、任务调度程序、发送和获取资源的命令调度程序，知道线程是否可用，此类不会执行这些类型的操作直接但通过通用函数模板。

例如:

struct ThreadProperties {
    // thread specific
    id,
    slept for,
    is locked,
    is waiting,
    is joined,
    has mutex, if so hold id to mutex - lockguard
    is shared,
    is active,
    has promise or future...
    who has ownership of,
    marked for release,
    marked for transfer

    // other mutex and lock_guard properties

    // function object address stored as `size_t` to represent an id
    // data object address stored as `size_t` to represent an id

    // etc.

};

class ThreadManager {
private:
    std::map<unsigned, ThreadProperites> threadTable;
public:
    default constructor

    storeIds into relevant containers

    store properties into relevant containers

    associate above containers into a map or lookup table

    find or look for specific ID and if found 
    check to see its current status and report it
    also check to see if it's in a priority queue 
    or task scheduler and determine if it is ready
    to do something, or change its internal state.

    other common methods of functionality associated with threads.
};

// function templates to act on threads according to the reporting of the manager above.

我打算实现这种设计，同时尝试维护针对 c++17 的现代 c++ 的最佳实践；这种设计是否适合适当的类设计以使其通用、模块化、可移植和高效使用？

最佳答案

线程和其他 std基元就像原始指针。您应该建立一个不暴露任何低级别的并发模型。 std线程原语为您提供了足够的工具来做到这一点。

了解即将推出的一些新内容——执行程序、流、协程、rangesv3、monadic futures 等。围绕这些内容对您的库进行建模。

尝试基于互斥锁、线程休眠和唤醒、阻塞、原子和共享数据的原始使用来编写行为良好的代码是一个陷阱。

举个例子:

struct thread_pool;
template<class T>
struct my_future:std::future<T> {
  template<class F>
  auto then( F&& f )&&
  -> std::future< std::result_of_t<F(T&&)> >;
  thread_pool* executor = 0;
};
template<>
struct my_future<void>:std::future<void> {
  template<class F>
  auto then( F&& f )&&
  -> std::future< std::result_of_t<F()> >;
  thread_pool* executor = 0;
};
struct thread_pool {
  template<class F=do_nothing>
  my_future<std::result_of_t<F()>> do_task(F&& f={});
};

这里我们讨论了从一个任务到另一个任务的管道数据，并以一个增强的 future<T> 结束。 .通过拆分(通过 shared_future)和合并(future<X> 加入 future<Y> 生成 future<X, Y> )来增强它。

也许更进一步，构建一个基于流的系统:

template<class In>
using sink = std::function<void(In)>;
template<class Out>
using source = std::function<sink<Out>>;
template<class In, class Out>
using pipe = std::function< source<In>, sink<Out> >;

然后支持将源转换为异步源。

不要建立一些巨大的抽象城堡并希望它是完整的，而是阅读这些东西，当你遇到一个问题，其中一个可以解决你的问题时，实现足以解决你的问题。第一次尝试时，您并不是从头开始编写无所不能的线程系统，所以不要尝试。写一些有用的东西，下次再写一个更好的。

关于c++ - 在实践现代 c++17 最佳实践的同时管理线程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49439929/