MTAThread and AutoComplete

I need to use the WaitHandle.WaitAll and TextBox.AutoCompleteMode.

The problem is that the first requires MTA and the latter STA.

Is there any way around this

rich

You can have one thread running in MTA and one in STA. Then do each thing on a different thread.

Ideally you would seperate all of your logic out in a way that makes sense. If you just want a quick fix, you could do this:

static void STAWaitAll(WaitHandle[] waitHandles) {
Thread t = new Thread(delegate() { WaitHandle.WaitAll(waitHandles); });
t.SetApartmentState(ApartmentState.MTA);
t.Start();
t.Join();
}

I was leaning towards your fix, but I really wanted my main UI thread to run as MTA

The UI launches a series of Async methods via BeginInvoke with the last one waiting on the results of the others to Invoke the result back to the UI.

Rather than having the last one started via BeginInvoke I will spin an MTA thread.

thanks

Hi,

I think you may take a look at the link below.

http://www.codeguru.com/Cpp/COM-Tech/activex/apts/article.php/c5529/

Commonly, I suggest you create the Winform Main UI Thread with STA attribute, as the link said above, this will not prevent you from creating another threads(asynchronous method will also create another thread, commonly the threads are from Thread Pool)

Because Winform and its contorls are not thread-safe, so commonly that is winform itself should run in STA apartment.

Also here is some link about multithreading programming about winform.
Safe, Simple Multithreading in Windows Forms, Part 1
(http://msdn.microsoft.com/library/en-us/dnforms/html/winforms06112002.asp)

Safe, Simple Multithreading in Windows Forms, Part 2
(http://msdn.microsoft.com/library/en-us/dnforms/html/winforms08162002.asp)

Safe, Simple Multithreading in Windows Forms, Part 3
(http://msdn.microsoft.com/library/en-us/dnforms/html/winforms01232003.asp)

Also for your scenario, if you want to wait all the other threads than the Main UI thread exits, I think you may try to do that in a new thread, so that this will not block the Winform UI response. After all the other threads exit, the thread can notify winform that.

If you still have any concern, please feel free to post here.

Best regards,
Peter Huang

The issue with the STA UI thread is all the marshalling that will occur with the ThreadPool. I really don’t want to pay that price.

Back in COM/C++ days you could CoInitialize several threads as STA and synchronize cross thread access without

marshalling the interface if you were in process; something the .NET doesn’t do hence the need for MTA.

Why is AutoComplete COM

rich

It's not just AutoComplete. There are several areas of Windows Forms that have dependencies on STA (AutoComplete, Clipboard, WebBrowser, FileDialog, ActiveX, etc).

I would strongly advise against running a Windows Forms UI thread in anything byt STA.

AutoComplete simply uses the OSes built-in autocomplete functionality; which was implemented using COM.

Hi Rich,

I agree with Whatabohr's suggestion, we recommend running Winform(UI) in STA thread.
Also when another thread need to access to the UI object in UI thread, we need to use Control.Invoke method which underlying implemented by SendMessage due to the UI control is not thread safe.

So a call onto UI thread Object, is just putting a message into the Message Queue of UI Thread.

If you still have any concern, please feel free to post here.

Best regards,
Peter Huang

Thanks.

My concern is not with using the Control.Invoke to talk to the UI. It is with the cost of cross thread marshalling that occurs with the STA objects. If you follow the rules for STA any object created in one apartment must be marshaled for use in another.

In my app a large number of objects are created in the main thread and heavily used by worker threads. When complete Control.BeginInvoke is used to update the UI.

Does the ThreadPool marshall objects created in STA apartments

rich

Hi Rich,

Thanks for your posting!

The STA cross apartments call will use the same marshalling mechanism in both .NET or Win32.
The only different is that in .NET approach, we have another .NET/Unmanaged code call marshalling which will pay more price than the Win32 approach.
http://www.codeproject.com/com/CCOMThread.asp

The reason why I mentions the Control.Invoke is that I assume the object you created on the Main thread have two categories.
1. It is a UI Object, which is commonly not threadsafe, so we need use Control.Invoke to use it.
2. It is not a UI Object, and I assume you have implemented the ThreadSafe mechanism. In this scenario, we can still use the Control.Invoke to invoke the call on the Main UI thread.
Also another approach, I think you may try to create all the Object which have implemented ThreadSafe on a new created MTA thread, so that other Working thread can access to it directly.

If you still have any concern, please feel free to post here.

Best regards,
Peter Huang

Thanks for the info.

The STA Marshalling issue can be significant when creating a rich UI control with multiple background threads.

With COM InProcess components we can cheat. We can create several STA apartments and communicate directly across threads if we implement our own synchronization or we can play it safe and marshal the interface.

The first is much faster when communicating with the object every few milliseconds.

Ideally, all the components would be in the MTA but this allows us to host STA components is situations where the component does not support MTA.

In .NET managed threads, if I don’t have the option of going around the STA marshalling as described above, then my only option is MTA. If my only option is MTA, then I’m out of luck if I put an unrelated TextBox on the screen that uses AutoComplete. I’m backed into a corner where my only options are Unmanaged code or degrading performance.

Do you see my dilemma

rich

Hi Rich,

Based on my knowledge, to invoke a method on UI Control on the main thread from another thread, we recommend you use the Control.Invoke which is implemented by SendMessage. Due to the Winform is not thread safe, we do not recommend you put it into MTA thread. Also .NET do have more payload than Win32, because if the .NET code underlyingly call the unmanaged code, it need P/invoke or COM interop marshalling(if .NET code call an unmanaged COM, we also need marshaller). Also for .NET code to run, the .NET runtime need to JIT the MSIL to native code firstly.

Also I know that we can write a FTM(Free threaded marshaller) to improve the performance in win32 COM. But it is hard to do that in .NET because all the job is implemented by the .NET runtime. In .NET world, we tend not to control the low level behavior of an application, e.g. the Memory management.

Anyway I do understand your concern in this scenario.
For the performance issue, I suggest post in the forum below.
Common Language Runtime
Discuss issues regarding the very core of .NET: Security, performance, hosting, base classes, interop, reliability, debugging, GC, and profiling are example topics.
http://forums.microsoft.com/MSDN/ShowForum.aspx ForumID=44&SiteID=1

The forum is primarily for issues involving .NET performance. We recommend posting appropriately so you will get the most qualified pool of respondents, and so other partners who regularly read the newsgroups can either share their knowledge or learn from your interaction with us.

If you still have any concern, please feel free to post here.

Best regards,
Peter Huang