[...]
I have two thread, when any one thread has done some changes , this
changes should be reflect on the other thread. So mutual
understanding between thread is necessary.
Is it possible to resolve this problem by using Inter process
communication
[IPC]?
It depends on what you want to do. First, I'll point out that you
definitely *don't* need IPC just for communicating between threads.
Threads have access to the same memory address space, and so can
communicate directly via data structures and variables.
IMHO, Kevin's answer isn't as helpful as it could be, mostly because the
word "events" describes two different things, one of which
(WaitHandle-based events) is directly useful for inter-thread
communications, and one of which (.NET events, using the "event" C#
keyword) is useful only in conjunction with other mechanisms designed for
inter-thread communications.
I personally do like using .NET events for communicating between objects,
whether in the same thread or not. They are great when you have something
in one object for which you want another object to be informed when it
happens. That is, an "event" occurs.
But they don't inherently offer
any cross-thread protection. Depending on what you're trying to
communicate, however, they are a good starting place (as Kevin suggests).
The main thing though is to be aware of a couple of things:
* You cannot use UI elements (Control-derived objects, mainly) across
threads directly. Anything that interacts with the underlying Windows
window object has to be executed on the same thread that created that
window object. That includes practically every method and property
defined in .NET for an object derived from Control. To access these, you
need to use Form.Invoke() or Form.BeginInvoke() to provide a delegate that
will be run on the same thread that created the object.
* For other communications, you need to protect the data being used to
communicate with some type of synchronization, so ensure that no other
thread is trying to read the data while one thread is writing to it, and
to ensure that all threads are always using the most up-to-date data. In
some cases, you can use a .NET object designed for inter-thread
communication directly for the communication, or you can use one of those
objects to control access to other data to ensure synchronization.
The "volatile" keyword can be used to ensure that each thread is using
up-to-date data, while objects like WaitHandle-based events, semaphores,
mutexes can be used for synchronization, as well as the "lock()" statement
in C# (I don't know if VB.NET or other .NET languages have something
similar, but I'd guess they do).
So, there's the basics. For anything more specific, we'd need to know
exactly what it is you're trying to communicate between threads. As an
example, given your vague description it is *possible* that it would be
sufficient to use an AutoResetEvent object that is set when the one thread
is done making whatever changes it wants to make, signaling to the other
thread (which would be stopped at a statement calling
AutoResetEvent.WaitOne()) that the changes have been done.
Pete
