Question

I want to make server application. In the beginning it should make thread for organizing every connection and write logs in Listbox. I have problem because i don’t know where can i make new thread which would have access to Form1.Listbox1. This is what i tried:

public class ServerLoop
{
    Form1 form1;
    public ServerLoop(Form1 f)
    {
        form1 = f;
    }
    public void loop()
    {
        form1.addConsoleMessage("test");
    }
}

And Form1 class:

public partial class Form1 : Form
{
    public Thread tServerLoop;
    public ServerLoop serverLoop;

    public Form1()
    {
        InitializeComponent();
    }

    private void Form1_Load(object sender, EventArgs e)
    {
        console.Items.Clear();
        players.Items.Clear();
        players.Items.Add("Witaj w serwerze");
        addConsoleMessage("test");
        serverLoop = new ServerLoop(this);
        tServerLoop = new Thread(serverLoop.loop);
        tServerLoop.Start();
    }

    private void connectButton_Click(object sender, EventArgs e)
    {

    }

    public void addConsoleMessage(String msg)
    {
        console.Items.Add(msg);
    }
}

Anyone knows what can i do to acheive this?

Answer 1

Well, you could use Invoke to marshal a delegate back onto the UI thread where that ListBox can be safely accessed.

public void loop() 
{
  form1.Invoke(new Action(
    () =>
    {
      form1.addConsoleMessage("test");
    }));
} 

But alas, this option is inferior. Actually, these marshaling techniques are generally terrible. Do not get me wrong. There is a time and place for Invoke (and the like), but this, like many situations, is not one of them.

• The code is ugly because you have to sprinkle Invoke calls all over the place.
• It forces you into a design where the UI thread and worker thread are tightly coupled.
• The worker thread is dictating the update frequency of the UI.
• It is inefficient.
• It can flood the UI message queue (at least it could with BeginInvoke).
• The worker thread has to wait for a response from the UI thread before it can proceed (it will with Invoke anyway).

So how would I solve this problem? Well, with the boring old System.Windows.Forms.Timer and the fancy new ConcurrentQueue<T> of course.

public partial class Form1 : Form                    
{
  private ConcurrentQueue<string> queue = new ConcurrentQueue<string>();

  public Form1()                    
  {                    
    InitializeComponent();                    
  }                    

  private void Form1_Load(object sender, EventArgs e)                    
  {                    
    console.Items.Clear();                    
    console.Items.Add("test");
    players.Items.Clear();                    
    players.Items.Add("Witaj w serwerze");                    
    Task.Factory.StartNew(
      () =>
      {
        while (GetSomeCondition())
        {
          string value = GetSomeValue();
          queue.Enqueue(value);
        }
      });
  }                    

  private void YourTimer_Tick(object sender, EventArgs e)                    
  {                    
    string value;
    while (queue.TryDequeue(out value)
    {
      console.Items.Add(value);
    }
  }                                        
}                    

So what do we have now.

• It looks elegant.
• Our background task knows only about a queue. The tight coupling has been broken.
• The UI thread is now dictating the update frequency…the way it should be.
• It is a lot more efficient.
• There is no chance that the UI message queue will get flooded.
• And finally, the worker can speed along merrily completely unware of what the UI thread is doing.

This solution is not completely devoid of disadvantages though. Now that we have our worker thread speeding along it is possible that it produces more items for the queue then what the UI thread can consume. It would not typically be a problem, but there are techniques for dealing with that.