Click here to Skip to main content
15,795,793 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more:
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
        'Call HandleClient(sock)
    End If


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?

Sergey Alexandrovich Kryukov 10-May-13 12:26pm    
This is a good idea, I voted 4. Not 5, as you don't really understand the essence of things: the threads of same process always share the memory, only each thread had is independent stack and context (in particular, the processor state should be saved and restored while switching between threads); that actually makes threads threads, preserving the structure of calls and returns. My answers (please see) explain how objects are accessed with you wrap the thread.

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.


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

Share this answer
onemorecoke 10-May-13 13:04pm    
Thank you so much SA for your great answer! You are correct in understanding my limit of knowledge on the subject. I did read one term you had that I am not familiar with. When you say "non-static method", does that refer to creating a new thread based on a single SUB as opposed to creating a thread based on a full class?
Sergey Alexandrovich Kryukov 10-May-13 13:16pm    
You are very welcome.
Your idea of using a separate class was already a very good move, and your understanding will come as you accumulate some more knowledge.

"Static" method is just the method which does not use the "this" reference to access the instance of the class, so it could be called no matter if such instance exist. Naturally, such method cannot access other instance members. Did you ever use any non-object-oriented languages? Static method is pretty much like that.

Now, in contrast, non-static method (aka instance method) has "this" reference passed as argument (it is implied, not shown in the list of method arguments). This is a reference to an instance of the class. A thread start method can be static or non-static. If it is non-static, it means "this" is implicitly passed, so the method gets a reference, in this case, to the instance of its declaring class, your wrapper. Is it more clear now?

onemorecoke 10-May-13 16:29pm    
Very well said! Yes, I understand your explanation and thank you for being so open with your time to answer.
Sergey Alexandrovich Kryukov 10-May-13 16:37pm    
My pleasure.
Good luck, call again.
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
Share this answer
onemorecoke 10-May-13 13:07pm    
Thank you Pete! I had a feeling that overall it might be better to do, but I was going off an example given to me and before I jump in all the way I wanted to make sure I was going down the right road. Everyone's advice and experience really helps!

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900