passing data between threads

[Mark Denardo]

Hi, I have multi-threaded application that requires one particular thread
(Non-Form based) to receive data from other threads. I know how to pass
control to Form Threads, but I believe there's no way to pass to Non-Form
Threads. So the only two solutions I can think of to handle this situation
is to (1) Keep the Non-Form Thread as is and set up a polling method to
watch for shared variables and respond appropriately, or (2) change the
Class to a Form so I can pass control to it from other threads.

Is there any other (and hopefully easier) way besides two way approaches
above??

 

[stand__sure]

depending upon your needs, a mutex or a semaphore may be more
appropriate. polling can get expensive.

can you give more details on your specific needs?

 

[Guest]

It doesn't have to specifically be a Form - a Control will do. I can remember
times when I've derived a worker class from Control purely in order to use
the InvokeMember method.

 

[Ken Tucker [MVP]]

Hi,

I would create a wrapper class to handle the thread. I would
add methods to start and stop the thread to the class. I also would add
some properties to accept the data you want to pass to the thread.

Ken
--------------------
Hi, I have multi-threaded application that requires one particular thread
(Non-Form based) to receive data from other threads. I know how to pass
control to Form Threads, but I believe there's no way to pass to Non-Form
Threads. So the only two solutions I can think of to handle this situation
is to (1) Keep the Non-Form Thread as is and set up a polling method to
watch for shared variables and respond appropriately, or (2) change the
Class to a Form so I can pass control to it from other threads.

Is there any other (and hopefully easier) way besides two way approaches
above??

 

[Armin Zingler]

It doesn't have to specifically be a Form - a Control will do. I can
remember times when I've derived a worker class from Control purely
in order to use the InvokeMember method.

If the other thread doesn't have a message loop, it will not execute the
invoked member.


Armin

 

[Mark Denardo]

I don't really understand how a control will help without a form in the
first place. Here's the big picture of my needs:

I have a central "Server" Thread that is a Form that I use to watch all
Client activity on and I have a "ListenToClients" Thread that in non-Form
based, that just sits and listens for Client requests and actions. I also
have a number of lets just call them "ClientsInteracting" Threads (non-Form
based) that are created by the server which allow Clients to interact and do
things. I have possibly a lot of these (could get up to 100-200 or so), so
I set them up in their own threads, because up to 10-20 clients could be
interacting on each of these threads and sending everything to the Server to
manage all this wouldn't be practical.

When a client wants to do or say something, it comes in on the
"ListenToClients" (non-Form) Thread and needs to get passed to the
"ClientsInteracting" (non-Form) thread somehow without burdening the Server
(Form) Thread.

So a passing data to a control doesn't help, unless I first make
"ClientsInteracting" a Form. Right? Or am I missing something.

 

[Mark Denardo]

Here's the big picture of my needs:

(repeated from a reply on another post
I have a central "Server" Thread that is a Form that I use to watch all
Client activity on and I have a "ListenToClients" Thread that in non-Form
based, that just sits and listens for Client requests and actions. I also
have a number of lets just call them "ClientsInteracting" Threads (non-Form
based) that are created by the server which allow Clients to interact and do
things. I have possibly a lot of these (could get up to 100-200 or so), so
I set them up in their own threads, because up to 10-20 clients could be
interacting on each of these threads and sending everything to the Server to
manage all this wouldn't be practical. When a client wants to do or say
something, it comes in on the "ListenToClients" (non-Form) Thread and needs
to get passed to the "ClientsInteracting" (non-Form) thread somehow without
burdening the Server (Form) Thread.

So when you say wrapper, you're talking about setting up a wrapper in an
already Formed Thread, that would control the "ClientsInteracting"
(non-Form) Thread? If this is what you're referring to, then in my case it
won't work, because I need to pass from (non-Form) Thread to (non-Form)
Thread.

 

[Mark Denardo]

When you say "message loop", your referring to what a Form does right? I'm
still trying to understand what the Framework does under the cover...

Because if I'm trying to pass data from one non-Form Thread to another
non-Form Thread, it doesn't work because the Non-Form thread doesn't have a
message loop - meaning if it ran out of things to do, it would just end,
where as if it's a form it sits and waits for user interaction. Is my
understanding correct here?

So that's why a non-Form Thread would need to set up polling, else it would
just end right?

 

[Mark Denardo]

Oh man, now your making me look up what semaphores and mutex do again. Here
the bigger picture, while I look these up:

(repeated from a reply on another post
I have a central "Server" Thread that is a Form that I use to watch all
Client activity on and I have a "ListenToClients" Thread that in non-Form
based, that just sits and listens for Client requests and actions. I also
have a number of lets just call them "ClientsInteracting" Threads (non-Form
based) that are created by the server which allow Clients to interact and do
things. I have possibly a lot of these (could get up to 100-200 or so), so
I set them up in their own threads, because up to 10-20 clients could be
interacting on each of these threads and sending everything to the Server to
manage all this wouldn't be practical. When a client wants to do or say
something, it comes in on the "ListenToClients" (non-Form) Thread and needs
to get passed to the "ClientsInteracting" (non-Form) thread somehow without
burdening the Server (Form) Thread.

I'm thinking that just setting the "ClientsInteracting" thread up as a form
will make all this go away...

 

[Armin Zingler]

When you say "message loop", your referring to what a Form does
right?
http://msdn.microsoft.com/library/e...erface/windowing/messagesandmessagequeues.asp


I'm still trying to understand what the Framework does under
the cover...

Application.Run contains the message loop. Control.BeginInvoke is a function
sending a kind of message to the thread that created the Control.
Application.Run processes this message. Without a message loop, the message
is not processed (I don't mention Application.Doevents here...).

Because if I'm trying to pass data from one non-Form Thread to
another non-Form Thread, it doesn't work because the Non-Form thread
doesn't have a message loop - meaning if it ran out of things to do,
it would just end, where as if it's a form it sits and waits for
user interaction. Is my understanding correct here?

So that's why a non-Form Thread would need to set up polling, else
it would just end right?

I think these are two different things: Notification and lifetime of a
thread.

I'm not a thread-notification specialist. I would probably add a "job" entry
into a collection that is available to both threads (the sender and the
receiver) and use Synclock for synchronisation.

And yes, the thread ends because there is nothing to do anymore.
Application.run contains the message loop that keeps the thread alive.


Armin

 

[stand__sure]

we seem to be going in circles here.

your code needs some way to "listen". an event driven model makes the
most sense (if this is truly a single application and not several).

if I correctly your scenario, you will have a variable number of
clients. this means that if you choose the polling approach, you will
possibly have to poll a variable number of objects. in general polling
is a bad idea and in your instance would be a VERY bad idea since it
will create a lot of excess work on the thread, etc. this is why
mutexes and semaphores were suggested.

Ken Tucker's suggestion about wrapping the thread in a class is
EXCELLENT advice -- you should ALWAYS do this (i.e. his advice extends
beyond your current needs.

at this point, SAMPLE CODE would be helpful! your description is
beginning to sound like MULTIPLE PROCESSES and not multiple threads.
Code would be most helpful.

to avoid spinning you in circles with generalities, if you have code
that gives you "illegal cross thread operation" errors, you are on the
right path -- if you post that code here, we can help you make it
work...