passing data between threads

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?

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.
"Mark Denardo" wrote:

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??

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
--------------------
"Mark Denardo" <ma*********@ru nbox.com> wrote in message
news:Y9******** ************@co mcast.com...
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??

"Bonj" <Bo**@discussio ns.microsoft.co m> schrieb

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

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 "ListenToClient s" 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 "ClientsInterac ting" 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
"ListenToClient s" (non-Form) Thread and needs to get passed to the
"ClientsInterac ting" (non-Form) thread somehow without burdening the Server
(Form) Thread.

So a passing data to a control doesn't help, unless I first make
"ClientsInterac ting" a Form. Right? Or am I missing something.
"Bonj" <Bo**@discussio ns.microsoft.co m> wrote in message
news:EC******** *************** ***********@mic rosoft.com...

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.
"Mark Denardo" wrote:

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??

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 "ListenToClient s" 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 "ClientsInterac ting" 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 "ListenToClient s" (non-Form) Thread and needs
to get passed to the "ClientsInterac ting" (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 "ClientsInterac ting"
(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.
"Ken Tucker [MVP]" <vb***@bellsout h.net> wrote in message
news:Ot******** ******@TK2MSFTN GP09.phx.gbl...

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
--------------------
"Mark Denardo" <ma*********@ru nbox.com> wrote in message
news:Y9******** ************@co mcast.com...
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??

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?
"Armin Zingler" <az*******@free net.de> wrote in message
news:ur******** ******@TK2MSFTN GP15.phx.gbl...

"Bonj" <Bo**@discussio ns.microsoft.co m> schrieb

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

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 "ListenToClient s" 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 "ClientsInterac ting" 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 "ListenToClient s" (non-Form) Thread and needs
to get passed to the "ClientsInterac ting" (non-Form) thread somehow without
burdening the Server (Form) Thread.

I'm thinking that just setting the "ClientsInterac ting" thread up as a form
will make all this go away...
"stand__sur e" <st*********@ho tmail.com> wrote in message
news:11******** *************@g 49g2000cwa.goog legroups.com...

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?

"Mark Denardo" <ma*********@ru nbox.com> schrieb

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

I'm still trying to understand what the Framework does under
the cover...
Application.Run contains the message loop. Control.BeginIn voke 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.Doe vents 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