Question

I am new to making threads so I experimented with some code and it seems to work. We have a wpf client interface that connects to an imaging device. We transmit the data from the interface to the central server for storage. I was advised by an external programmer that making an anonymous thread on an embedded system isn't a great idea. But I couldn't figure out why.

Here is a snippet of my code.

new Task(() =>
            {
                using (TCPconnector = new TcpClient(App.CT.CTIpAddress, Convert.ToInt32(App.CT.CTIpPort)))
                {
                    try
                    {

                        using (stream = TCPconnector .GetStream())
                        {
                            writer = new BinaryWriter(stream);
                            writer.Write(deviceCT);
                        }
                    }
                    catch (Exception ex)
                    {
                        Logger.Log.Instance.LogFiles["Client"].Add(ex.ToString(), Logger.Log.Status.Exception);
                    }
                    finally
                    {
                        if (stream != null) stream.Close();
                        if (TCPconnector != null) TCPconnector .Close();
                        if (writer != null) writer.Close();
                    }
                }


            }).Start();

He said theoretically I can call the functions inline instead of declaring them as the Task method. Since the only reason I'd want to fork if off is if I think the socket calls will take too long and block the current thread (if it is a UI thread). I think it actually will block.

I think that since it is on the UI thread it needs to execute on a background thread. A failed TCP connection can take a very long time (in UI hang time) to time out.

So with that, why is an anonymous thread not a great idea on an embedded system?

Was it helpful?

Solution

Using Slugster's comment:

The external developer may be technically correct, he is incorrect in applying that statement to your code because you are not running an anonymous thread on the physical imaging device.

In the long run, the developer and I came to a truce and the code stayed on the client side machine. He was afraid that if it were ever to move onto the imaging device it self (to run standalone) then we would have a problem.

Stepping through the code with VS yielded no problem with this anonymous thread.

Good Luck.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top