在c#中与多线程相关的事件必须场景吗?

时间:2021-09-05 00:36:33

I am wondering that in which scenario we must use events technique in multithreading and there is no other way around? I have seen cases we may use another syncronization techniques like Monitor wait and pulse to implement this.

我想知道在哪种情况下,我们必须在多线程中使用事件技术,而没有其他方法?我曾见过一些案例,我们可能会使用另一种同步技术,比如Monitor wait和pulse,来实现这一点。

Can anyone help me out to understand events in Multithreading ?

谁能帮助我理解多线程中的事件?

3 个解决方案

#1


3  

There are none. You can always handle it at a lower level of abstraction (until you're pushing around 1s and 0s, you can always handle anything at a lower level of abstraction). However, it is often cleaner and/or simpler to do so. http://msdn.microsoft.com/en-us/library/ms228966.aspx gives advice on the matter, but there are no "must scenarios".

没有。您总是可以在较低的抽象级别处理它(直到您处理1和0,您总是可以在较低的抽象级别处理任何东西)。然而,这样做通常更简洁和/或更简单。aspx在这个问题上给出建议,但是没有“必须的方案”。

#2


3  

I would support @Jon Hanna's answer but emphasize the fact that .Net events implement a commonly-used pattern (Observer) with sufficient elegance that it is sheer perversity in most instances to implement it any other way.

我支持@Jon Hanna的回答,但我要强调的是。net事件实现了一种常见的模式(Observer),这种模式非常优雅,在大多数情况下,以其他方式实现它是完全反常的。

This is demonstrated by the way events turn up in the .Net Framework classes themselves, not just as a language construct for application programmers to play with. They are a first-class language feature, and as such to consciously avoid using them does not make sense. It would be like avoiding foreach loops just because there are other ways to achieve the same end.

这一点可以通过事件在。net Framework类中出现的方式来证明,而不仅仅是应用程序开发人员使用的语言结构。它们是一流的语言特性,因此有意识地避免使用它们是没有意义的。这就像避免foreach循环,仅仅因为有其他方法可以达到相同的目的。

See here for an overview of Observer pattern and how events address this in .Net. It's unlikely that anything you build using other .Net programming methods would match the simplicity and expressiveness of the event implementation.

请参阅这里的观察模式概述,以及事件如何在。net中解决这个问题。使用其他. net编程方法构建的任何东西都不太可能与事件实现的简单性和表现力相匹配。

#3


2  

Multithreaded Programming with the Event-based Asynchronous Pattern

使用基于事件的异步模式进行多线程编程

The above article should give you some excellent resources on how to use events in a Multi-threaded environment.

上面的文章应该提供一些关于如何在多线程环境中使用事件的优秀资源。

#1


3  

There are none. You can always handle it at a lower level of abstraction (until you're pushing around 1s and 0s, you can always handle anything at a lower level of abstraction). However, it is often cleaner and/or simpler to do so. http://msdn.microsoft.com/en-us/library/ms228966.aspx gives advice on the matter, but there are no "must scenarios".

没有。您总是可以在较低的抽象级别处理它(直到您处理1和0,您总是可以在较低的抽象级别处理任何东西)。然而,这样做通常更简洁和/或更简单。aspx在这个问题上给出建议,但是没有“必须的方案”。

#2


3  

I would support @Jon Hanna's answer but emphasize the fact that .Net events implement a commonly-used pattern (Observer) with sufficient elegance that it is sheer perversity in most instances to implement it any other way.

我支持@Jon Hanna的回答,但我要强调的是。net事件实现了一种常见的模式(Observer),这种模式非常优雅,在大多数情况下,以其他方式实现它是完全反常的。

This is demonstrated by the way events turn up in the .Net Framework classes themselves, not just as a language construct for application programmers to play with. They are a first-class language feature, and as such to consciously avoid using them does not make sense. It would be like avoiding foreach loops just because there are other ways to achieve the same end.

这一点可以通过事件在。net Framework类中出现的方式来证明,而不仅仅是应用程序开发人员使用的语言结构。它们是一流的语言特性,因此有意识地避免使用它们是没有意义的。这就像避免foreach循环,仅仅因为有其他方法可以达到相同的目的。

See here for an overview of Observer pattern and how events address this in .Net. It's unlikely that anything you build using other .Net programming methods would match the simplicity and expressiveness of the event implementation.

请参阅这里的观察模式概述,以及事件如何在。net中解决这个问题。使用其他. net编程方法构建的任何东西都不太可能与事件实现的简单性和表现力相匹配。

#3


2  

Multithreaded Programming with the Event-based Asynchronous Pattern

使用基于事件的异步模式进行多线程编程

The above article should give you some excellent resources on how to use events in a Multi-threaded environment.

上面的文章应该提供一些关于如何在多线程环境中使用事件的优秀资源。