Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: VB.NET
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
Posted 10-May-13 7:02am
Comments
Sergey Alexandrovich Kryukov at 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.
—SA
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

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 Smile | :) ) 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
  Permalink  
v2
Comments
onemorecoke at 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 at 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?
 
—SA
onemorecoke at 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 at 10-May-13 16:37pm
   
My pleasure.
Good luck, call again.
—AS
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

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
  Permalink  
Comments
onemorecoke at 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)

  Print Answers RSS
0 Sergey Alexandrovich Kryukov 555
1 Kornfeld Eliyahu Peter 409
2 Maciej Los 369
3 DamithSL 196
4 OriginalGriff 188
0 OriginalGriff 6,353
1 DamithSL 4,854
2 Maciej Los 4,466
3 Kornfeld Eliyahu Peter 4,058
4 Sergey Alexandrovich Kryukov 3,897


Advertise | Privacy | Mobile
Web02 | 2.8.141220.1 | Last Updated 10 May 2013
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100