We Keep Coding

C# - Only run immediate function with threading?

Here's what I have. When my application starts up, it creates a thread and runs my startListening() function. But what it seems to do, is run any other functions called within startListening under the same thread. Is there a way I can make it so that ONLY the things immediately inside of startListening are ran with that thread, and not the functions called from within that?
It would just make it a lot easier for me when referencing controls and things that aren't within that thread so I don't have to Invoke each time.
EDIT: Maybe this isn't the right thing to be asking. I know I had to Invoke with setting textboxes, but now I need to make a timer enabled. Its not throwing any exceptions when I try to enable it, but rather just not "ticking". Here's my code:
private void beginListenerThread()
{
Thread thread1 = new Thread(startListening);
thread1.Start();
}
private void startListening()
{
timer1.enabled = true;
}
But it doesn't tick.
Thanks!

No, that's not possible automatically. If you are able to modify the method that should be called on another thread, change the calls to other methods so that they're run on the originating thread. If you're using Windows Forms, use this.Invoke or this.BeginInvoke, for example.

Yes, this is the kind of trouble you'll run into when you use a class that is not thread-safe on a thread. The Winforms Timer class generates Tick events from a little hidden helper window, a window that receives WM_TIMER messages generated by the Windows SetTimer() api function and turns them into Tick event calls. That window is created when you enable the timer.
What goes wrong here is that this window gets created on the wrong thread. It needs a message pump to dispatch the WM_TIMER notifications, that thread doesn't have one. It could have one by calling Application.Run() but you don't want to go there.
Follow the advice given in the MSDN Library article's Remarks section:
The Windows Forms Timer component is single-threaded, and is limited to an accuracy of 55 milliseconds. If you require a multithreaded timer with greater accuracy, use the Timer class in the System.Timers namespace.
Or the System.Threading.Timer class, a timer class that's a bit less cranky.

ProgressBar doesn't update when program running on weak computers

When I run the program in one fast computer, the ProgressBar and a Label(that write the progress too) gets perfectly updated. When I run it on a weak computer (like PIV or old c2d) the ProgressBar and the form stay freezed (but the program run until it finishes).
How can I resolve that? With background worker?

If you're using a progress bar, I'm guessing whatever the task is is definitely long enough to warrant a background/worker thread. There are lots of options (BackgroundWorker, spinning up your own thread, etc). BackgroundWorker is probably the easiest.

Yes, you should put your processing into a background thread. Using a background worker is a good idea, because you can simply update the controls from its ProgressChanged event.

There are some methods that allow the UI to be refereshed in long-running tasks.
1- run the task in another tread/in an anychronous method call and then using this.Invoke to change the progressbar.
2- Force the UI to refresh at some points in the task by calling Application.DoEvents() in winforms for instance.

Background threading in c#

I am currently working with threading and backgroundworker in c#. The problem im having is that this. Say i have a main thread for user interaction and a worker thread to process txt files(various editing operations). Then after the backgroundthread runs its contents once, i have a timer start that performs another set of operations. I want these new operations that the timer runs ever x minutes to be run in the same background thread without running the previous txt related operations it ran before the timer started. How can this be done?

You should just use a System.Timers.Timer, which will run its callback on a thread pool thread.
It shouldn't matter which specific thread you run on (as long as it's not the UI thread).
If, for some reason, it does matter (eg, if you're using a single-threaded COM object), you'll need to make a dedicated thread that waits for things to do using a thread-safe queue of delegates.

You want to use an Event Driven method to execute function calls on your worker thread from your UI thread. The way to accomplish this is using BeginInvoke, you can read more about how to use it here: http://www.dreamincode.net/forums/topic/35616-cross-thread-communication-in-c%23/

Add a while loop to the end of your background worker:
while(!stop) { Thread.Sleep(yourIntervalinMilliseconds); ... }
I'd create a stop bool somewhere that the thread looks at when you want it to kick out.

Performing periodic audits and best practice

I'm doing a windows form and would like an audit task to happen every 30 seconds. This audit is essentially checking a series of services on remote computers and reporting back into a richtextbox the status.
Current I have this running in an endless background thread and using an invoker to update the richtextbox in the main form.
Is this best practice? If I made an endless loop in my main form that would prevent any of my buttons from working, correct?
I'm just curious if every time I want to create a periodic audit check I have to create a new thread which checks the status or file or what have you?
Edit: I looked further into the Timer class and decided to go with System Timer as it proved to be better with a longer function. Thanks for pointing me in the right direction.

You should look into the Windows Forms Timer class. You don't want a loop in your main form. It's better to use the timer to fire events which can be processed asynchronously on another thread.

(I assume this is a winform application)
Invoking on the main thread is the way to go. But what about using a timer instead of an endless loop? It gives you more control. And a the timer function would execute on it's own thread.
It's good practice to let long going work execute on a background thread, so that the main thread can work with the UI.

Winforms should I multi thread or use event timer?

I currently have a thread that listens for data from the network and then runs rules on it. I then want to pass the data to the GUI. I am worried about having a deadlock in the GUI. I cant figure out were to put the mutexes on the GUI side. I am also using c# and dotnet 3.5.
What I have come up with is
1) Using a timer to create an event and dump the thread. Worried about performance.
2) Use an intermediary event to copy the data to GUI.
3) Dig in and figure out thread safe way of using GUI.
What do you think is best way to proceed?
Edit: Here is the solution I am using. I pass in the changed element and then protect the big object with a mutex. I use helper function to switch threads using InvokeRequired then BeginInvoke with a delegate. Pulled from reading the answers and then following links until reaching Threading in Windows Forms by Jon Skeet.
delegate void UInt32ParameterDelegate(UInt32 n);
public void UpdateLocation(UInt32 n)
{
if (InvokeRequired)
{
// We're not in the UI thread, so we need to call BeginInvoke
BeginInvoke(new UInt32ParameterDelegate(UpdateLocation), new object[] { n });
return;
}
// Must be on the UI thread if we've got this far
this.engine.location.UpdateBusy.WaitOne();
// do the work in here
this.engine.location.UpdateBusy.ReleaseMutex();
}

Synchronization is very easy in Windows Forms. You can call Control.Invoke() in the background thread. The thread will stall until the delegate has finished running on the UI thread. No sync required at all.
If stalling the thread is a problem, use Control.BeginInvoke(). You'll have to protect the object(s) you pass to the delegate with a lock if the thread might alter them while it continues running. That's rarely the case in a producer-consumer scenario, the thread can simply create new objects.
Do make sure that you don't Invoke() too often. Do it more frequently than about 1000 times per second and the UI thread will stop pumping Windows messages, being bogged down by handling the invoke requests. Since it is human eyes you're trying to please, invoking more than about 25 times per second is just wasted effort. Pool intermediate results in a collection object.

I hope I understand your problem correctly.
After the background thread reads the data and does whatever it wants, it should use Invoke to call a method on the GUI thread. That method would update anything that should be updated in the GUI.

Never read from the network on the GUI thread. It's only a matter of time before your application runs during a network outage and your GUI hangs as a result. This will really frustrate your users.
In your situation I think the best approach is to have a background thread complete the read operation. Then take the resulting data and move it back to the GUI thread via a SynchronizationContext Post or Send method.

you should just pass an event from your network thread to your UI thread.
then cross threads using begininvoke so you don't get a cross thread exception.
Need help getting info across a UI thread and another thread in C#

You could use a backgroundworker that will process the datareading in a background thread and when it's done you can end the backgroundworker triggering it's RunWorkerCompletedEventHandler. In the RunWorkerCompletedEventHandler you can update your GUI thread with the result.

Isn't easier to just throw a delegate who raise an event that inform the form to refresh itself?