Thread.Suspend()

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi White Spirit,
you should look at the AutoResetEvent / ManualResetEvent classes, these
are used for thread syncronization. The basic premise is that a thread is
not allowed to pass through the XXXResetEvent unless the WaitHandle is
signalled (i.e. opening the door) then threads can pass through.

http://msdn2.microsoft.com/en-us/library/system.threading.manualresetevent.aspx

In this way you can make your threads wait until they have some work to do.

Hope this helps.
Mark Dawson
http://www.markdawson.org
 
I hope that sort of makes sense. The important thing is for each thread
receiving messages from the clients to be running at all times and the
threads that send newly received messages from the clients to be blocked
until a new message is ready. Using the Monitor class didn't seem
appropriate as the threads aren't competing for access to a resource.
Click to expand...

Just because they aren't competing for access to a resource doesn't
mean you can't use monitors. Monitor.Wait/Notify/NotifyAll exist for
situations like this.
 
I've read that it is not recommended to use Thread.Suspend and
Thread.Resume to control execution of threads and that use of the
Monitor class is preferred. I'm writing a server that lets users chat
together using a GTK# text window and use of Thread.Suspend and
Thread.Resume seems to be the only way to achieve this.

The server has two arrays of threads. One thread array is for each
client to attach to a port (say 1024) to receive the new messages from
the server that the users type. The other thread array is for each
client to attach to a different port (say 1025) where the server
receives messages from the users, which are then relayed to the clients.

The threads that send messages to the clients call
Thread.ThisThread.Suspend() after a new client has connected. When a
thread that receives messages from a client has a new message from the
connected client user, it copies the message to a static string and then
wakes each thread in the thread array responsible for sending the
message to the connected client. Once the threads have sent the
contents of the static message string to their respect clients, they
sleep again until woken by a thread receiving a new message.

I hope that sort of makes sense. The important thing is for each thread
receiving messages from the clients to be running at all times and the
threads that send newly received messages from the clients to be blocked
until a new message is ready. Using the Monitor class didn't seem
appropriate as the threads aren't competing for access to a resource.
 
Back
Top