WeN*_*ers 2 c# f# multithreading components design-patterns
我最近一直在研究代码,特别是在内部使用线程的面向组件的代码.这是一个不好的做法.我看到的代码来自一个F#示例,它展示了使用基于事件的编程技术.我不能在版权侵权的情况下发布代码,但它确实启动了自己的线程.这被认为是不好的做法,或者自己编写的代码是否可以完全控制线程创建是否可行.我确实指出,这段代码不是一个可视化组件,而且非常"从头开始构建".
在线程有用的组件创建的最佳实践是什么？
我对此完全是语言不可知的,f#示例可能是在c#或python中.
我担心缺乏对组件运行时间和资源占用的控制,这个例子只是实现了另一个线程,但据我所知,没有什么能阻止这种类型的设计产生尽可能多的线程,到你的程序允许的极限.
我确实想过像对象注入这样的方法,所以第四,但线程很奇怪,因为它们是从组件角度来看纯粹的"动作"而不是"模型,状态,声明"
任何帮助都会很棒.
这是一个太笼统的问题,无法承担任何答案比"依赖"更具体:-)
有些情况下,在组件中使用内部线程是完全有效的,有时则没有.这必须根据具体情况决定.但总的来说,由于线程确实使代码更难以测试和维护,并增加了细微的,难以发现的错误的机会,所以只有在确实有使用它们的决定性因素时才应谨慎使用它们.
合法使用线程的一个示例是工作线程,其中处理事件的组件启动需要很长时间才能执行的操作(例如冗长的计算,Web请求或广泛的文件I/O),并产生一个单独的线程来完成这项工作,这样控件就可以立即返回到界面来处理进一步的用户输入.如果没有工作线程,UI将长时间完全没有响应,这通常会使用户生气.
另一个例子是冗长的计算/过程,它很适合于并行执行,即它由许多或多或少相似大小的较小的独立任务组成.如果存在强大的性能要求,则使用工作线程池以并发方式执行各个任务确实有意义.许多语言为此类设计提供高级支持.
请注意,组件通常可以自由分配和使用任何其他类型的资源,从而在无数其他方面造成严重破坏 - 您是否曾担心组件占用所有内存,耗尽可用文件句柄,保留端口等？其中许多可能会导致系统内的全局问题,而不是产生额外的线程.
| 归档时间： |
|
| 查看次数： |
201 次 |
| 最近记录： |