[RESOLVED] [2008] WaitAll for multiple handles on a STA thread is not supported

[obi1kenobi]

I am using the ThreadPool for some background processing (see this thread) and because I don't know any better, I made my code use WaitHandles and AutoResetEvents. The problem is that I'm getting a NotSupportedException on the WaitHandle.WaitAll(waitHandles) line, saying the following: "WaitAll for multiple handles on a STA thread is not supported.". I've added the <MTAThreadAttribute()> attribute before the method using WaitHandles, however this has no effect. Any ideas? And may setting MTA instead of STA have any unwanted side-effects? I don't want to solve one problem by creating a hundred more...

A solution which uses a different method to notify the main thread of the completion of the worker threads would also be acceptable.

@jmcilhinney: I remember you posted a link to the MSDN website, to a part which explained multi-threading and async operations, however I am sorry to say that it was too complex for me to understand well enough to be able to use it on my own... Thank you anyway, since I believe the link will be of great use to me as soon as I have learned enough to understand it.

[MaximilianMayrhofer]

This is a simple MSDN article on callbacks with the threadpool. Very straightforward.

[obi1kenobi]

Did you actually read my post?

The problem is that I'm getting a NotSupportedException on the WaitHandle.WaitAll(waitHandles) line, saying the following: "WaitAll for multiple handles on a STA thread is not supported.". I've added the <MTAThreadAttribute()> attribute before the method using WaitHandles, however this has no effect.

Any ideas? And may setting MTA instead of STA have any unwanted side-effects? I don't want to solve one problem by creating a hundred more...

Jmcilhinney provided a similar straightforward example so I know how to use the ThreadPool now. But try running the VB equivalent of the code from that MSDN article and you'll get the same exception. May be straightforward, but it doesn't work, or at least it didn't work for me.

[jmcilhinney]

You are quite right that that C# code works as is while the VB equivalent doesn't. I added the MTAThread attribute to the Main method and it did work, so that's obviously the issue. If your app is WinForms though, you don't have that luxury. Not without disabling the Application Framework anyway. According to the documentation for the MTAThreadAttribute class:

In the .NET Framework version 2.0, new threads are initialized as ApartmentState.MTA if their apartment state has not been set before they are started. The main application thread is initialized to ApartmentState.MTA by default. You can no longer set the main application thread to ApartmentState.STA by setting the Thread.ApartmentState property on the first line of code. Use the STAThreadAttribute instead.

That's obviously not the case for VB Console apps so it may well not be for VB WinForms app either.

Try disabling the Application Framework for your app and start it from a Main method with the MTAThread attribute applied to see if that fixes the issue. If it does and you don't need any features of the Application Framework specifically then you can leave it at that. If it does work but you want to keep using the Application Framework, as you theoretically should be able to, we'll do a bit more digging and see if we can find a better solution.

[jmcilhinney]

That's obviously not the case for VB Console apps so it may well not be for VB WinForms app either.

I just ran a VB WinForms app with this code:

MessageBox.Show(Threading.Thread.CurrentThread.GetApartmentState().ToString())

and, sure enough, it said STA. From what I've read it seems that there is no way to make the main thread MTA other than to apply the MTAThread attribute to its entry point. As you don't have access to its entry point with the Application Framework enabled, it appears that you're going to have to choose between disabling the Application Framework or finding another way to be notified that your threads have completed.

[obi1kenobi]

The project which contains the code is a Class Library project, however the project it's intended for is a WinForms application. The Application Framework is vital for the application and I don't have the option of disabling it. The project deadline is January 16th, so I'm willing to do whatever it takes to make it work, including rewriting the Class Library in C# if that'll solve the problem.

Can I add the MTAThread attribute to just one class of a project? If so, I'll rewrite the class in C# and append it to a C# project in my solution.

Perhaps there may be a method which doesn't use WaitHandles. Something along the lines of raising an event on the UI thread each time a ThreadPool work item is finished. The event would count how many times it has been raised and after the last work item is finished it would invoke a new method, passing the finished data as an argument. How does that sound?

If it sounds ok, then I'll need some help with raising the event on the UI thread, I think I can do the rest myself.

[jmcilhinney]

You have to apply the MTAThread attribute to the method that serves as the entry point for a thread. In a class library you have no knowledge of the method that started the thread. The only way I can see to use WaitAll is if you start a new thread in your class library with the MTAThread attribute applied to the entry method. You can then call WaitAll within that method.

Also, I just tried running the VB equivalent of that aforementioned C# code again but this time I changed this:

' Wait for all threads in pool to calculation...
WaitHandle.WaitAll(doneEvents)

to this:

' Wait for all threads in pool to calculation...
For Each handle As WaitHandle In doneEvents
    handle.WaitOne()
Next

and that worked fine without applying the MTAThread attribute.

[obi1kenobi]

I'm assuming that will have the same effect without a significant performance impact, right?

EDIT: Ok I just tried it and it worked like a charm! Thank you so much! I'd gladly rate but it says I need to spread it around some more first =/