如何创建“线轴” C# 类的服务
我正在研究 C# 编程，该语言相当简洁。我想我对面向对象编程有很好的理解，以及运行多个线程在高层次上意味着什么，但实际的实现我是如前所述的擦洗。
我想要做的是创建一个工具，该工具将有许多线程运行并相互独立交互，每个线程将服务自己的任务并可以调用其他线程。
我确保通信的策略（不会丢失来自不同线程同时发生的多个更新的任何内容）是在每个类上创建一个可以调用外部的类似假脱机的任务，并将任务添加到给定线程，或为这些线程提供假脱机服务。我不确定是否应该将其放在类上或外部，并让类本身调用假脱机来执行新任务并跟踪假脱机。在这里，我特别考虑如何在空线轴获取任务时向类发出信号（侦听器方法，因此如果任务想要在新内容到达时被唤醒，则可以订阅池），或者进行“每 X 秒检查一次”任务和下一个任务未安排”方法
创建这个的一个好的策略是什么，我应该在实际的类中还是外部创建它？实现中的关键区域是什么，因为“繁忙等待检查”允许它仅添加新作业并删除实际假脱机上的作业，而信号发送则需要添加/删除作业，还需要转到睡眠状态发出关键信号时，突然对进入关键区域时要做什么的假脱机提出了很高的要求，因为这可能会导致阻塞，导致其他阻塞，以及可能出现不可预见的死锁。
I am looking into a C# programming fairly scrub to the language. I would like to think I have a good understanding of object oriented programming in general, and what running multiple threads means, at a high level, but actual implementation I am as said scrub.
What I am looking to do is to create a tool that will have many threads running and interacting with each other independent, each will serve their own task and may call others.
My strategy to ensure communication (without losing anything with multiple updates occurring same time from different threads) is on each class to create a spool like task that can be called external, and add tasks to a given thread, or spool service for these. I am not sure if I should place this on the class or external and have the class itself call the spool for new tasks and keeping track of the spool. Here I am in particular considering how to signal the class if an empty spool gets a task (listener approach, so tasks can subscribe to pools if they want to be awoken if new stuff arrive), or make a "check every X seconds if out of tasks and next task is not scheduled" approach
What would a good strategy be to create this, should I create this in the actual class, or external? What are the critical regions in the implementation, as the "busy wait check" allows it to only be on adding new jobs, and removing jobs on the actual spool, while the signaling will require both adding/removing jobs, but also the goto sleep on signaling to be critical, and that suddenly add a high requirement for the spool of what to do if the critical region has entered, as this could result in blocks, causing other blocks, and possible unforeseen deadlocks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我经常在各种系统上使用这样的模型。我为代理定义一个类，称为“AgentClass”，为请求定义一个类，称为“RequestClass”。该代理有两个抽象方法，“submit(RequestClass *message)”和“signal()”。通常，代理中的线程构造一个生产者-消费者队列并在其上等待 RequestClass 实例，submit() 方法将传递的 RequestClass 实例排队到队列中。 RequestClass 通常包含一个“命令”枚举，告诉代理需要做什么，以及执行请求所需的所有数据和“发送者”代理实例。当代理收到请求时，它会打开枚举以调用正确的函数来执行请求。代理仅对 RequestClass 中的数据起作用 - 结果、错误消息等放置在 RequestClass 的数据成员中。当代理执行了请求（或失败并生成错误数据）时，它可以将请求提交给发送者（即请求已异步执行），或者调用发送者的 signal() 函数，这表示发送者正在等待的事件（即请求是同步执行的）。
我通常在启动时构造固定数量的 RequestClass 实例，并将它们存储在全局“池”PC 队列中。任何需要发送请求的代理/线程/任何东西都可以将 RequestClass 实例出队，填充数据，将其提交（）给代理，然后异步或同步等待执行请求。完成后，RequestClass 将返回到池中。我这样做是为了避免连续的 malloc/free/new/dispose，简化调试（我使用计时器将池级别转储到状态栏，因此我总是注意到请求是否泄漏或被双重释放），并消除需要在应用程序关闭时显式终止线程，（如果多个线程仅读取/写入比应用程序表单等寿命更长的数据区域，则应用程序将轻松关闭，并且操作系统可以处理所有线程 - 有数百篇关于'干净地关闭应用程序上的线程关闭”-我从不打扰！）。
这种消息传递设计非常能抵抗死锁，因为唯一的锁（如果有的话）位于 PC 队列中，尽管如果您足够努力，您当然可以实现它:)
这是否是您似乎需要的系统，还是我理解错了？
平均值，
马丁
I use such a model often, on various systems. I define a class for the agents, say 'AgentClass' and one for the requests, say 'RequestClass'. The agent has two abstract methods, 'submit(RequestClass *message)' and 'signal()'. Typically, a thread in the agent constructs a producer-consumer queue and waits on it for RequestClass instances, the submit() method queueing the passed RequestClass instances to the queue. The RequestClass usually contains a 'command' enumeration that tells the agent what needs doing, together with all data required to perform the request and the 'sender' agent instance. When an agent gets a request, it switches on the enumeration to call the correct function to do the request. The agent acts only on the data in the RequestClass - results, error messages etc. are placed in data members of the RequestClass. When the agent has performed the request, (or failed and generated error data), it can either submit() the request back to the sender, (ie. the request has been performed asynchronously), or call the senders signal() function, whch signals an event upon which the sender was waiting, (ie. the request was performed synchronously).
I usually construct a fixed number of RequestClass instances at startup and store them in a global 'pool' P-C queue. Any agent/thread/whatever than needs to send a request can dequeue a RequestClass instance, fill in data, submit() it to the agent and then wait asynchronously or synchronously for the request to be performed. When done with, the RequestClass is returned to the pool. I do this to avoid continual malloc/free/new/dispose, ease debugging, (I dump the pool level to a status bar using a timer, so I always notice if a request leaks or gets double-freed), and to eliminate the need for explicit thread termination on app close, (if multiple threads are only ever reading/writing to data areas that outlive the application forms etc, the app will close easily and the OS can deal with all the threads - there are hundreds of posts about 'cleanly shutting down threads upon app close' - I never bother!).
Such message-passing designs are quite resistant to deadlocks since the only locks, (if any), are in the P-C queues, though you can certainly achieve it if you try hard enough:)
Is this the sort of system that you seem to need , or have I got it wrong?
Rgds,
Martin