Threading and raising events

  • Thread starter Thread starter Sacha
  • Start date Start date
S

Sacha

hello,
I'm using C# and having a little thread communication problem :
-one thread (and its associated object) receives UDP packets using the
UdpClient class
-another object (say Object2) needs to raise an event from another thread
when a packet is received.
-as Object2 *could* be sitting on the main thread, it cannot be blocked
waiting on the "UdpThread"
-Object2 is not a System.Window.Forms.Control
-I'd rather avoid polling some synchronized variable.

in the good old win32 times, i would have allocated a window handle in
Object2's thread and
used PostMessage from the UdpThread.=> no polling and no locking...

Any advice on what should be done to remain in the .NET spirit while
achieving such goals ?

thanks in advance
Sacha De Vos
 
Hi, Sacha

did you try to use simple way of declaring event in udp thread object and
assigning event handler to it, which calls delegate in object2? As this can
be done asynchronously - using internal threads - it could be easiest way
out.

Did you have any problems with this?

You can use old way too - P/Invoke and Win32 is available in .Net. There are
other ways, of course, too.
Maybe it will help to check for example
http://msdn.microsoft.com/msdnmag/issues/03/02/Multithreading/

HTH
Alex
 
Hello Alex,
As I was focusing on application logic, i first did this the "unsafe way"
calling a delegate from the UDP thread
without taking care of threads and possible data corruption. It turned out
to be working nicely. But i can't
just leave it as is. The application i'm writing requires a very large
object graph and several threads will eventually
be acting on it. I can picture future bugs which will then become harder to
point out.

Also, i investigated the asynchronous delegates thing, but it seems this
will spawn a new thread. Which is not
what i need.

This project needs to go on, so i think i'll go the good old win32 way,
while still looking for possible .Net solutions

Here is a little win32 style sample class that solves my problem.
Looking at its simplicity, and how PostMessage isn't part of the libraries,
i figured there would be some .Net way of doing such things. (still looking
for it tho)


//*************************
//this is not production quality code, all error checks left intentionaly
out
//*************************
using System;
using System.Windows.Forms;
using System.Threading;
using System.Runtime.InteropServices;


namespace aSyncTest3
{
/// <summary>
/// a Test class for multithreading
/// </summary>
public class Class1 : NativeWindow
{
//Taken from WinUser.h
private const int WM_USER = 0x0400;
//This message will be sent from the threaded method
private const int WM_MYMESSAGE = WM_USER + 1;
private Thread myThread;

//i couldn't find PostMessage in the .Net libraries
//does that mean this isn't the way to go ?
[DllImport("user32.dll")]
private static extern bool PostMessage (int HWnd, int wMsg, int wParam,
int lParam);

public Class1()
{
//Create a window handle so that i receive messages in WndProc
CreateHandle(new CreateParams());
}
//Call this method to start the thread
public virtual void Start()
{
myThread = new Thread(new System.Threading.ThreadStart(ThreadStart));
myThread.Name = "TestThread";
myThread.Start();
}
//This method belongs to TestThread (myThread)
public virtual void ThreadStart()
{
//run for 10 minutes
for (int i=0; i<600; i++)
{
//send a message to the WndProc method
PostMessage(Handle.ToInt32(), WM_MYMESSAGE, i, 0);
//wait one second
Thread.Sleep(1000);
}
}
//Release resources (do not forget to call this !)
public virtual void Close()
{
if (myThread!=null)
{
myThread.Abort();
ReleaseHandle();
}
}
//Raise events to main thread from this method
protected override void WndProc(ref Message m)
{
switch (m.Msg)
{
case WM_MYMESSAGE:
MessageBox.Show("Raise an event from here !");
break;
}
base.WndProc(ref m);
}
}
}
 
I once used good ol' PostThreadMessage which does not require a window to be
associated with the thread - but a message loop still should be present
though.
 
Ahyes, i forgot about this one...
I'm not sure yet of the "thread location" of my message receiving object
though.
It could really sit in main thread, depending on the library usage...

Sacha
 
Back
Top