VB.Net - 最好让线程使用单独的类吗？ [英] VB.Net - Is it best to have threads use separate classes?

问题描述

我使用下面的代码监视tcp套接字并处理请求：

 ' 接受连接，直到需要停止服务。 
     不 m_stopRequested 
 
 '  等待传入连接。等待最多1秒。 
 sock = m_listenSock.AcceptNextConnection（ 1000 ）
 如果（不（sock   没什么））然后 
 ' 启动一个线程 
t = 新线程（ AddressOf  我 .HandleClient）
 m_numActiveThreads = m_numActiveThreads +  1  
 t.Start（sock）
 ' 调用HandleClient（袜子） 
 结束 如果 
 
 循环 

创建时一个新的线程并使用Me.HandleClient，它只是同一个代码中的一个SUB，可以这样做，还是应该自己创建一个单独的类？我想真正的问题是，当创建新线程时，是否为每个线程创建了一个完全不同的内存空间？



谢谢

解决方案

有一些与访问跨线程共享数据和线程参数相关的方面导致我（基于长期众所周知的想法，这里没有大发明:-)）到将线程包装在一个单独的类中的重要性和巨大好处的想法，特别是在.NET中，其中线程启动方法可以是一个实例（非静态方法）。在这种情况下，您可以将包装器实例的完全访问权限传递给线程方法。此外，它有助于封装对可以存储在线程包装器中的共享数据（它，它的锁定机制）的访问。



有关详细信息，请参阅我过去的答案：

如何将ref参数传递给线程 [ ^ ]，
带锁的
：更改线程（生产者）启动后的参数 [ ^ ]，

C＃中的MultiThreading [ ^ ]。



CodeProject成员VSNetVbHarry很高兴提供VB.NET示例代码：传递线程LongRunningProcess的参数 [ ^ ]。



我希望在我的回答中使用C＃不会阻止你理解这种方法。在所有情况下，欢迎您提出后续问题。







和你的问题本身，因为它已经制定，在我对这个问题的评论中得到回答。

-SA

我想简单的答案是肯定的，但只有当你认为如果该线程的任务被封装在它自己的类中时，你的代码将更易于管理。只要看看你提供了什么，我就不得不说 - 因为那个线程负责套接字连接。您可以在从该套接字连接的自定义类创建一个对象后，将对象添加到集合中，而不是记录您创建的线程数，并执行诸如终止连接，排队要发送的消息之类的操作，获取每个套接字连接的状态，只需枚举您创建的列表，并调用为该事件准备的方法。



我发现创建了一个类一个线程变得越来越受欢迎你需要控制/与之沟通的越多。



希望这会有所帮助，

- Pete

I am using this code below to monitor a tcp socket and process requests:

' Accept connections until the service needs to be stopped.
Do While Not m_stopRequested

    ' Wait for an incoming connection. Wait a max of 1 second.
    sock = m_listenSock.AcceptNextConnection(1000)
    If (Not (sock Is Nothing)) Then
        ' start up a thread
        t = New Thread(AddressOf Me.HandleClient)
        m_numActiveThreads = m_numActiveThreads + 1
        t.Start(sock)
        'Call HandleClient(sock)
    End If

Loop

When it creates a new thread and using Me.HandleClient, which is just a SUB in the same code, is this OK to do or should I create a separate class on its own? I guess the real question is, when the new thread is created, do it make a whole different memory space for each thread?

Thanks

解决方案

There are some aspects related to access to cross-thread shared data and thread parameters which led me (on the base on long well-known ideas, no big inventions here :-)) to the idea of importance and great benefits of wrapping a thread in a separate class, especially in .NET, where a thread start method can be an instance (non-static method). In this case, you can pass full access of the wrapper instance to the thread method. Besides, it helps to encapsulate access to the shared data (that it, its locking mechanism) which can be stored in the thread wrapper.

For further detail, please see my past answers:
How to pass ref parameter to the thread[^],
with lock: Change parameters of thread (producer) after it is started[^],
MultiThreading in C#[^].

The CodeProject member VSNetVbHarry was so nice to provide a VB.NET sample code: Passing arguments to a threaded LongRunningProcess[^].

I hope C# used in my answer won''t prevent you from understanding the approach. In all cases, your follow-up questions will be welcome.

[EDIT]

And your question itself, as it is formulated, is answered in my comment to the question.

—SA

I guess the simple answer is yes, but only if you believe that your code would be more manageable / legible if that thread''s task were encapsulated in it''s own class. Just looking at what you''ve provided, I would have to say yes - because that thread is responsible for a socket connection. Instead of recording the number of threads you''ve created, you could add objects to a collection after creating one from your custom class for that socket''s connection, and do things like kill the connection, queue up messages to be sent, get the status of each individual socket connection and all by simply enumerating the list you created, and calling methods you prepare for that event.

I find that creating a class for a thread becomes more and more desirable the more you need to control / communicate with it.

Hope this helps,
- Pete

这篇关于VB.Net - 最好让线程使用单独的类吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！