Styjun

The background-thread is an UDP listener. As soon as a certain type of message is received, the main thread has some work to do.
My current solution works. But I'm in doubt of the implementation.

My question:

• Is this a proper way to handle these "simple" situations?


• Is there another simple and elegant solution that's more commonly accepted?

The server class:

class UdpServer

 UdpClient listener;

 Messenger messenger;

 public UdpServer(Messenger messenger)
 
 this.messenger= messenger;
 

 public void StartListening()
 
 listener = new UdpClient(settings.Port);
 IPEndPoint groupEP = new IPEndPoint(IPAddress.Any, 15000);

 try
 
 while(true)
 
 byte[] bytes = listener.Receive(ref groupEP);

 messenger.Message = string.Format("0 : 1", 
 groupEP.ToString(), 
 Encoding.ASCII.GetString(bytes, 0, bytes.Length));
 
 
 catch(SocketException e)
 
 messenger.Message = string.Format("UDP server error: 0", e.Message);
 
 finally
 
 listener.Close();
 
 

Thread "safety" is sort of implemented in the way that the thread reading the message will only check the value when the Event has been triggered. The event will only be triggered when the value is completely written. As long as each thread gets its own messenger instance, no trouble with threads sharing variables will arise, right?

The messenger class:

//this class is used to transport messages from the receiving threads to the main UI thread.
//subscribe to statusmessageevent in order to receive the messages

class Messenger

 private string message; 
 public string Message
 
 set
 
 message = value;
 StatusMessageEventHandler(message);
 
 

 public event EventHandler<string> StatusMessageEvent;
 private void StatusMessageEventHandler(string message)
 
 StatusMessageEvent?.Invoke(this, message);
 

The main thread:

 static void Main(string[] args)
 

 var UdpMessenger = new Messenger();

 UdpMessenger.StatusMessageEvent += MessengerEvent;

 var UdpServer = new UdpServer(UdpMessenger);

 Task.Factory.StartNew(() => UdpServer.StartListening());

 Console.ReadKey();
 


 private static void MessengerEvent(object sender, string e)
 
 Console.WriteLine(string.Format("Received Message: 0", e));
 

You write in the comments:

I was under the impression that because the instance was created on the main thread, the event would be called there too.

Objects in C# and .NET are not thread-affine by default. You need to implement this behavior manually. Creating a generic object on a thread doesn't cause that object to raise events on the thread the object was created on. Events are raised on the caller thread, if you don't provide a custom implementation that changes this.

With your current code, the StatusMessageEvent events will be raised on the caller thread (the one that runs the StartListening method).

If you have a GUI application (e.g. WPF, WinForms), you can manually marshal to the main thread when necessary.

class Program

 static SynchronizationContext mainThreadContext;

 static void Main()
 
 // app initialization code here

 // you could also do this somewhere in your main window
 mainThreadContext = SynchronizationContext.Current;
 

 static void MessengerEvent(object sender, EventArgs<string> e)
 
 // do additional stuff here that can be done on a background thread

 // The UpdateUI method will be executed on the UI thread
 mainThreadContext.Post(_ => UpdateUI(), null);
 

 static void UpdateUI() 

Instead of the SynchronizationContext, you can use Control.BeginInvoke (WinForms) or Dispatcher.BeginInvoke (WPF).

If you have a console app and for some reason need to marshal to the main thread... Well, then you need to implement your own SynchronizationContext and something like a task scheduler or a dispatcher or a main loop. That's not easy.