Develop Reference

System.Threading.Thread - perform operation on it

Ok so lets say all I have is the reference of a System.Threading.Thread called thread A and I'm on another thread, lets say thread B. Now I need to execute a bit of code on thread A for a moment, then switch back. Using the reference I have, how can I Invoke thread A to do an action in it?
Well I'm making a c++/cli library. One of my objects has a thread affinity. I enter a method, I need to swap threads like you would in a Dispatcher.Invoke.
void AllegroSharp::Display::DrawToBackBuffer(BitmapImage^ image)
{
al_draw_bitmap(image->GetBitmap(), (float)image->Rect->Position->X, (float)image->Rect->Position->Y, 0);
}
DrawToBackBuffer gets called on thread B and al_draw_bitmap needs to be called on Thread A, which I have a reference to. How can I do this on thread A? Thread B is just some thread that c# spawned when I did a Task.Run in managed code.

Threads run one set of instructions from start to finish. If thread A is already running, it will execute whatever code it's been told to run from start to finish. You won't be able to change what it's running unless it is actively monitoring some shared memory for instructions on what to do next. Typically the way you implement this is by having a thread run in a loop and, inside that loop, check a message queue. Then have other threads add messages to that queue to give the looping thread work to do. There are a lot more details to make it work right, but that's the basic idea.
If, in your particular scenario, thread A is the application's GUI thread, this message passing mechanism is already set up for you, and you can use Control.Invoke (winforms) or Dispatcher.Invoke (WPF) to pass a unit of work to the GUI thread and wait for it to be completed.
Edit: this answer has been rendered less applicable by the addition of new information to the question. Ah well.

How to improve performance of background task in WPF?

I'm building a WPF app which will do some heavy work in the background. The issue is that when I run the task in the unit tests, it usually takes about 6~7s to run. But when I run it using TPL in WPF app, it takes somewhere between 12s~30s to run. Is there a way to speed up this thing. I'm calling COM api of LogParser to do the real work.
Update:
My code for calling Log Parser API looks like below
var thread = new Thread(() =>
{
var logQuery = new LogQueryClassClass();
var inputFormat = new COMEventLogInputContextClassClass
{
direction = "FW",
fullText = true,
resolveSIDs = false,
formatMessage = true,
formatMsg = true,
msgErrorMode = "MSG",
fullEventCode = false,
stringsSep = "|",
iCheckpoint = string.Empty,
binaryFormat = "HEX"
};
try
{
Debug.AutoFlush = true;
var watch = Stopwatch.StartNew();
var recordset = logQuery.Execute(query, inputFormat);
watch.Stop();
watch = Stopwatch.StartNew();
while (!recordset.atEnd())
{
var record = recordset.getRecord();
recordProcessor(record);
recordset.moveNext();
}
recordset.close();
watch.Stop();
}
catch
{
}
finally
{
if (logQuery != null)
{
Marshal.ReleaseComObject(logQuery);
GC.SuppressFinalize(logQuery);
logQuery = null;
}
}
});
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
thread.Join();
The thing now is with this change, I can see about 3 - 4s improvement in debugging mode, but not when I hit Ctrl + F5 to run it which is quite beyond me. How come??

The problem here is that the COM object you're using will only run on an STA thread. Several people already suggested this, but I decided to check, just to be sure. I installed the LogParser SDK, and here's what it puts in the registry for the CLSID associated with the MSUtil.LogQuery ProgID:
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{8CFEBA94-3FC2-45CA-B9A5-9EDACF704F66}]
#="LogQuery"
"AppID"="{3040E2D1-C692-4081-91BB-75F08FEE0EF6}"
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{8CFEBA94-3FC2-45CA-B9A5-9EDACF704F66}\InprocServer32]
#="C:\\Program Files (x86)\\Log Parser 2.2\\LogParser.dll"
"ThreadingModel"="Apartment"
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{8CFEBA94-3FC2-45CA-B9A5-9EDACF704F66}\ProgID]
#="MSUtil.LogQuery.1"
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{8CFEBA94-3FC2-45CA-B9A5-9EDACF704F66}\VersionIndependentProgID]
#="MSUtil.LogQuery"
It's that "ThreadingModel"="Apartment" that's the clincher. This COM class is declaring that it can only run on an STA thread.
Both the TPL and the BackgroundWorker use MTA threads. The consequence of this is that when you use the LogParser from either a TPL task or a BackgroundWorker the COM runtime detects that you're on the wrong kind of thread, and will either find or create an STA to host the object. (In this particular case it'll use what's called the 'host STA', a thread that COM creates specially for this purpose. There are some scenarios in which it'll use your main UI thread instead, but that's not the case here.)
COM then automatically marshals any calls from your worker thread over to that STA thread. It does this via a Windows message queue, so for each method you execute (and remember, property accessors are just methods in disguise, so this applies to property use too), your worker thread will send a message to that STA thread, that STA thread's message pump then has to pick that message up and dispatch it, at which point the COM runtime will call the method on the LogParser for you.
This is slow if you've got an API that involves a high volume of calls.
This is neither a WPF nor a Windows Forms issue by the way. It is entirely to do with using an STA-based COM object from a non-STA thread. You could reproduce exactly the same problem with a console app too, if you were using a non-STA thread in that. And the problem isn't specific to either the TPL or the BackgroundWorker - it will afflict anything that uses the thread pool, because thread pool threads all use MTA, not STA.
The solution is to use an STA thread. And the best way to do that is create a dedicated thread. Use the Thread class in the System.Threading namespace to launch your own thread. Call its SetApartmentState method before starting it. Make sure that the code that creates instances of objects from the LogParser API is running on that thread, and also make sure that you only ever use those objects from that thread. This should fix your performance issues.
Edited 21st Feb 2013 to clarify:
Note that it's not simply enough to ensure that you are using the COM object from an STA thread. You must use if from the same STA thread on which you created it. Basically, the whole reason for having the STA model is to enable COM components to use a single-threaded model. It enables them to assume that everything that happens to them happens on one thread. If you write multi-threaded .NET code that uses an STA thread from multiple threads, it will, under the covers, ensure that the COM object gets what it wants, meaning that all access will go through the thread it belongs to.
This means that if you call it from some other thread than its home STA thread, then even if that other thread also happens to be an STA thread, you'll still be paying the cross-thread price.
Edited 25th Feb 2013 to add:
(Not sure if this is relevant to this particular question, but could well be of interest to other people landing on this question through a search.) A downside of moving work onto a separate worker thread is that if you want to update the UI in any way as a result of processing these records, you're now on the wrong thread. If you're using databinding an INotifyPropertyChanged, WPF will automatically handle the cross-thread change notification for you, but this can have significant performance implications. If you need to do a lot of work on a background thread, but that work needs to end up updating the UI, you may need to take steps to batch those updates. It's not completely trivial - see the series of blog entries starting here: http://www.interact-sw.co.uk/iangblog/2013/02/14/wpf-async-too-fast

COM uses message queues for IPC. I'm unclear what determines which message queue, but I suspect it's the shell message queue because the Delphi debugger and Outlook used to play merry hell with each other. My unproven hypothesis is that an out of process COM server can be stalled by something else stallings the shell message queue. Windows has timeouts to prevent this sort of thing from totally locking up the system but it can cause massive slowdown in affected processes. My solution would be to avoid COM. You could check this by commenting out the parts that actually use COM and timing the process.

How is this possible: OnPaint processed while in WaitOne

I have a ManualResetEvent. At one point, I wait on that event using WaitOne. To my amazement, I received an OnPaint event while in the WaitOne. This happens quite often too.
The stack trace looks like this:
I understood that a WaitOne would block the current thread and would not allow any other code to be executed until the event fires.
Could someone explain what happens here?

This is by design. The CLR honors the contract of a single-threaded apartment (STA). The main thread of a GUI app is STA as is required in Windows programming, the [STAThread] attribute on the Main() method ensures that.
Hard rules for an STA thread are that it must pump a message loop (like Application.Run) and can never block. Blocking an STA thread is highly likely to cause deadlock when background threads use any COM apartment threaded objects. There are many of them, the clipboard and WebBrowser are common ones you'll encounter in a .NET program. Many less visible ones as well, available as .NET wrapper classes.
The CLR ensures blocking can't cause deadlock by pumping a message loop when you use the lock statement or call the Wait method of the synchronization classes. Or Thread.Join(). That message loop dispatches the WM_PAINT message, causing the Paint event to run.
You need to restructure your program to ensure this doesn't cause a problem. Pretty important to focus on not blocking the main thread at all. It is very rarely needed when you have, say, the BackgroundWorker class or Control.BeginInvoke() at your disposal. For some kind of odd reason the Mutex class doesn't do this kind of pumping, that could be another way. Although deadlock is lurking around the corner if you do.

I have seen this behavior too for the lock() statement. Apparently the .net framework Thread classes starts a message loop when waiting for a lock on the UI thread. This just explains what is happening. The reasoning could be to prevent deadlocks when working with legacy STA COM objects. I am not aware of a way to prevent this.

BackgroundWorker component in services

I know the BackgroundWorker should not be used in Windows Services but would anyone have a good online reference explaining why?

BackgroundWorker relies on a current SynchronizationContext being set in order to function. It's really intended and designed specifically for working with UI code.
It's typically better in a service to self-manage your threads, since there are no UI synchronization issues. Using the threading API (or .NET 4 Task API) is a much better option here.

Well, it's okayish to use a BGW in a service, it just doesn't do anything especially useful. Its reason for being is its ability to raise the ProgressChanged and RunWorkerCompleted events on a specific thread. Getting code to run on a specific thread is a very non-trivial thing to do. You cannot simply inject a call into the thread while it is executing code. That causes horrible re-entrancy problems. The thread has to be 'idle', in a state where inject code doesn't cause trouble.
Having a thread in an idle state is a fairly unnatural condition. You use threads to run code, not for them to be idly spinning its heels. This is however the way a UI thread works. It spends 99% of its time in the message loop, waiting for Windows to tell it to do something. A button click, a paint request, a keyboard press, that sort of thing. While it is inside the message loop, it is in fact idle. A very good time to execute injected code.
Which is what Winforms' Control.Begin/Invoke and WPF's Dispatcher.Begin/Invoke do. They put a delegate in a queue, the queue is emptied and the delegate targets executed by the message loop. The WindowsFormsSynchronizationContext and DispatcherSynchronizationContext classes are the synchronization providers that uses them. Winforms and WPF replace SynchronizationContext.Current with an instance of them. Which in turn gets used by BGW to raise the events. Which makes them run on the UI thread. Which allows you to update the non thread-safe user interface components from a worker thread.
You can probably see where this is heading, a service uses neither. The default synchronization provider doesn't synchronize anything. It simply uses a threadpool thread to call the Send or Post callback. Which is what will happen when you use BGW in a service. Now there is actually no point at all in having these events. You might as well let the DoWork handler call the event handling methods directly. After all, the thread on which DoWork runs is just another threadpool thread as well.
Well, no real harm done, other than making it quite a bit slower.

I've used BackgroundWorker in windows services many times without any ill effect. While its use of SynchronizationContext may be unnecessary, I haven't observed it causing problems or poor performance.

what should i avoid doing on background thread in winforms

besides updating GUI controls from background threads, is there any other operations that should avoid being done on background threads in winforms?

Oh, there are plenty of traps. BGW doesn't do much to protect you from the usual hazards of threaded programming. And adds some of its own:
Variables that are accessed from both the BGW and the UI thread must be protected by a lock.
Do not update a bound data source in a BGW. The control updates will be done on the BGW thread but will not generate an exception.
Don't call ReportProgress() too often. Doing it more than about 1000 times per second will freeze the UI thread. About 25 times/sec is enough.
Careful with the userstate argument you can pass to ReportProgress(). It must not be modified by the BGW after the call.
Don't loop on the IsBusy property in the UI thread, it will deadlock.
The BGW thread will be aborted when the main form closes. Watch out for necessary cleanup.
Be sure to inspect the Error property in the RunWorkerCompleted event, it tells you when something went wrong.

This is sort of broad. Don't do anything in a background thread if you don't need to; that is, don't thread out some code just because you feel like it. Use threads where it is appropriate such as for long running tasks that you do not want to interrupt the GUI and so forth. Also, if you end up just calling Application.DoEvents() from your main UI thread just waiting on a task from another thread, you might think about keeping one thread and doing the work in small pieces in a loop where you would repaint the GUI with DoEvents() calls. This is just a suggesiton; however, of course, many times you do need to create multiple threads.
Perhaps you can ask about particular situations?

Well, the reason you should not update GUI controls on a background thread is that the GUI control classes are not threadsafe. So, you can generalize that: don't mess with instances of non-threadsafe classes from a background thread if there is some other thread that might also use them. (That's broad, I know, but anything that breaks that rule could get you in trouble).
But I think the gist of your question is whether or not you've covered all the bases that Control.Invoke() was created to cover. If so, yes, you have ... Control.Invoke was specifically designed for the fact that controls are not threadsafe, and therefore, other threads should only modify controls via Control.Invoke().

I agree with Bobby that your question is too broad. Instead start with the assumption that if you have to create a worker thread, you're not going to put anything in it except what absolutely has to be there to complete the required task.