Threading Question
-
Dear Sirs, I've read google, MSDN and this site quite a bit and can't quite come up with the answer. I've created a program (server) that is multi-threaded. Here are some descriptions: Listener thread: This thread sits and listens for TCP connections. When it gets one, it creates a thread for that connection which gets data from that connection and interacts with the database, spawns processes, whatever the client asks for. Scheduler thread: Certain tasks are scheduled to occur on the server, this thread sits tight and when the appropriate time (specified in config file) comes, it executes the tasks that need to happen one at a time (which then probably connect via the listener). I would also like a GUI to monitor progress from the clients. I currently have the following main method:
//[System.STAThread]
public static void Main(string[] args)
{
_con = new DW_DB_Connection();//establishes connection with SQL database in ctor for use by clients.
Start_Threads(); //starts listener and scheduler
//System.Windows.Forms.Application.Run(new UI());
}If I use a GUI, I need STA Thread, right? My question is this: does
STAThreadAttributediminish the power of my application to multi-thread aggressively (and allow it to scale quite large)? From what I've read, it might be the case that STA only has an effect when the application uses COM (here). The scheduler and listener do not...I think, but Windows Forms certainly does. But other sources say it changes the apartment state of the current thread to be single threaded. Let me know what you think.In Christ, Aaron Laws http://ProCure.com
-
Dear Sirs, I've read google, MSDN and this site quite a bit and can't quite come up with the answer. I've created a program (server) that is multi-threaded. Here are some descriptions: Listener thread: This thread sits and listens for TCP connections. When it gets one, it creates a thread for that connection which gets data from that connection and interacts with the database, spawns processes, whatever the client asks for. Scheduler thread: Certain tasks are scheduled to occur on the server, this thread sits tight and when the appropriate time (specified in config file) comes, it executes the tasks that need to happen one at a time (which then probably connect via the listener). I would also like a GUI to monitor progress from the clients. I currently have the following main method:
//[System.STAThread]
public static void Main(string[] args)
{
_con = new DW_DB_Connection();//establishes connection with SQL database in ctor for use by clients.
Start_Threads(); //starts listener and scheduler
//System.Windows.Forms.Application.Run(new UI());
}If I use a GUI, I need STA Thread, right? My question is this: does
STAThreadAttributediminish the power of my application to multi-thread aggressively (and allow it to scale quite large)? From what I've read, it might be the case that STA only has an effect when the application uses COM (here). The scheduler and listener do not...I think, but Windows Forms certainly does. But other sources say it changes the apartment state of the current thread to be single threaded. Let me know what you think.In Christ, Aaron Laws http://ProCure.com
If you just create a new WinForms project, everything you need will be included. However,your threads cannot modify the UI directly. You need to use Invoke for that.There are several very good articles here on CodeProject about .Net multi-threading in a GUI.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
If you just create a new WinForms project, everything you need will be included. However,your threads cannot modify the UI directly. You need to use Invoke for that.There are several very good articles here on CodeProject about .Net multi-threading in a GUI.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001Dear Mr. Simmons, Thanks for the response. I'm not really multi-threading in a GUI, but my multi-threaded application uses a GUI. The UI is the last thing to be initialized. It's not much of a difference if any, but I thought I would point that out. Beyond that, I'm just trying to make sure that my program in fact uses the .Net Free-Threading (right?) model, not a scheduled single-thread when I use the
STAThreadAttribute. Thanks again.In Christ, Aaron Laws http://ProCure.com
-
Dear Sirs, I've read google, MSDN and this site quite a bit and can't quite come up with the answer. I've created a program (server) that is multi-threaded. Here are some descriptions: Listener thread: This thread sits and listens for TCP connections. When it gets one, it creates a thread for that connection which gets data from that connection and interacts with the database, spawns processes, whatever the client asks for. Scheduler thread: Certain tasks are scheduled to occur on the server, this thread sits tight and when the appropriate time (specified in config file) comes, it executes the tasks that need to happen one at a time (which then probably connect via the listener). I would also like a GUI to monitor progress from the clients. I currently have the following main method:
//[System.STAThread]
public static void Main(string[] args)
{
_con = new DW_DB_Connection();//establishes connection with SQL database in ctor for use by clients.
Start_Threads(); //starts listener and scheduler
//System.Windows.Forms.Application.Run(new UI());
}If I use a GUI, I need STA Thread, right? My question is this: does
STAThreadAttributediminish the power of my application to multi-thread aggressively (and allow it to scale quite large)? From what I've read, it might be the case that STA only has an effect when the application uses COM (here). The scheduler and listener do not...I think, but Windows Forms certainly does. But other sources say it changes the apartment state of the current thread to be single threaded. Let me know what you think.In Christ, Aaron Laws http://ProCure.com
Hi, this is how I understand the issue: the STA/MTA choice does not affect managed code; it exists in order to orchestrate how COM objects are used, i.e. in STA all COM accesses are sequenced, so no two threads are actively executing COM code. That would be relevant only in a few cases; only some GUI Controls force you to use STA, OpenFileDialog and similar dialogs are the most popular ones. For a server application, STA typically will be fine. If you need further convincing, just create a little project (default is STA) and give it a few (say 10) threads containing a while(true) loop including (1) a for loop counting to 1 billion and (2) a Console.WriteLine(string) statement with a different string for each thread. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
-
Hi, this is how I understand the issue: the STA/MTA choice does not affect managed code; it exists in order to orchestrate how COM objects are used, i.e. in STA all COM accesses are sequenced, so no two threads are actively executing COM code. That would be relevant only in a few cases; only some GUI Controls force you to use STA, OpenFileDialog and similar dialogs are the most popular ones. For a server application, STA typically will be fine. If you need further convincing, just create a little project (default is STA) and give it a few (say 10) threads containing a while(true) loop including (1) a for loop counting to 1 billion and (2) a Console.WriteLine(string) statement with a different string for each thread. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
Dear Mr. Pattyn, I hope you're right, and I'll assume you are. I'm not so sure the example really proves the point, though, because there could be some scheduling or something that causes the example to look multi-threaded when in fact, the one thread's slice is actually being sliced up more or something like that. As you can probably see from my comments, it's all a mystery to me, but I'll keep the
STAThreadAttributeup and contact you when it messes up. ;-)In Christ, Aaron Laws http://ProCure.com
-
Dear Mr. Pattyn, I hope you're right, and I'll assume you are. I'm not so sure the example really proves the point, though, because there could be some scheduling or something that causes the example to look multi-threaded when in fact, the one thread's slice is actually being sliced up more or something like that. As you can probably see from my comments, it's all a mystery to me, but I'll keep the
STAThreadAttributeup and contact you when it messes up. ;-)In Christ, Aaron Laws http://ProCure.com
I'm pretty confident my take on the matter is right; I understood they invented the apartment stuff to allow multi-threaded apps to use COM components that had been designed without thread-safety in mind. Therefore STA enforces sequential access. And then they decided to make STA the default in .NET, since otherwise too many people would fall in the OpenFileDialog trap. If you encounter clear proof otherwise, I sure want to hear from you and investigate. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
-
Dear Mr. Pattyn, I hope you're right, and I'll assume you are. I'm not so sure the example really proves the point, though, because there could be some scheduling or something that causes the example to look multi-threaded when in fact, the one thread's slice is actually being sliced up more or something like that. As you can probably see from my comments, it's all a mystery to me, but I'll keep the
STAThreadAttributeup and contact you when it messes up. ;-)In Christ, Aaron Laws http://ProCure.com
-
Then look at the CPU utilization, it can't go above 1 core if they're just using clever scheduling instead of true multithreading.
Dear Mr. Aptroot, This is correct. I'll have to profile it that way later (when I get some clients). But I would hate to develop the application, then figure out I'm only getting one thread later and have to restructure!! That's why I wanted to know now.
In Christ, Aaron Laws http://ProCure.com
-
Dear Mr. Aptroot, This is correct. I'll have to profile it that way later (when I get some clients). But I would hate to develop the application, then figure out I'm only getting one thread later and have to restructure!! That's why I wanted to know now.
In Christ, Aaron Laws http://ProCure.com
that is why I suggested you run a little test, such as:
public void Runner(object dummy) {
string text=dummy as string;
for(;;) {
for(int i=0; i<1000000000; i++) {} // should take a few seconds, very busy!
Console.WriteLine(text);
}
}Create a Console App, have it create N background threads executing Runner, each with a different text argument, and watch Task Manager :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
-
Hi, this is how I understand the issue: the STA/MTA choice does not affect managed code; it exists in order to orchestrate how COM objects are used, i.e. in STA all COM accesses are sequenced, so no two threads are actively executing COM code. That would be relevant only in a few cases; only some GUI Controls force you to use STA, OpenFileDialog and similar dialogs are the most popular ones. For a server application, STA typically will be fine. If you need further convincing, just create a little project (default is STA) and give it a few (say 10) threads containing a while(true) loop including (1) a for loop counting to 1 billion and (2) a Console.WriteLine(string) statement with a different string for each thread. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
Your explanations sounds like STA is a per-project setting. It's not. It's actually a per-thread setting, and the attribute on void Main just controls the setting for the main thread. You can have both STA threads and MTA threads in the same application. And yes, you can have multiple STAs running concurrently. COM objects living in a STA have all their calls executed on the thread associated with that STA (calls are marshaled to that thread and executed sequentially). COM objects living in a MTA have their calls executed by any MTA thread, so there can be many calls running concurrently. Of course, all this is revelant only for threads that create COM objects. Some Windows Forms controls require the GUI thread to be in a STA, but apart from that, threading apartement doesn't matter for a pure .NET application.
-
Your explanations sounds like STA is a per-project setting. It's not. It's actually a per-thread setting, and the attribute on void Main just controls the setting for the main thread. You can have both STA threads and MTA threads in the same application. And yes, you can have multiple STAs running concurrently. COM objects living in a STA have all their calls executed on the thread associated with that STA (calls are marshaled to that thread and executed sequentially). COM objects living in a MTA have their calls executed by any MTA thread, so there can be many calls running concurrently. Of course, all this is revelant only for threads that create COM objects. Some Windows Forms controls require the GUI thread to be in a STA, but apart from that, threading apartement doesn't matter for a pure .NET application.
Thanks for clarifying that. I have known this, but it faded away a bit, and that fact confirms your final statement, it not being very relevant for a pure .NET application, which is what I do most of the time. I do recall threads could choose their STA/MTA inclination, but only once. What isn't clear to me (I should look it up actually) is the consequences of the STA/MTA choice made on static Main(); does that only affect the main thread, or does it set the default for all threads? :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
-
Your explanations sounds like STA is a per-project setting. It's not. It's actually a per-thread setting, and the attribute on void Main just controls the setting for the main thread. You can have both STA threads and MTA threads in the same application. And yes, you can have multiple STAs running concurrently. COM objects living in a STA have all their calls executed on the thread associated with that STA (calls are marshaled to that thread and executed sequentially). COM objects living in a MTA have their calls executed by any MTA thread, so there can be many calls running concurrently. Of course, all this is revelant only for threads that create COM objects. Some Windows Forms controls require the GUI thread to be in a STA, but apart from that, threading apartement doesn't matter for a pure .NET application.
Dear Mr. Grunwald, Thanks for the explanation. That's right, I was thinking of it as a program setting, not a thread setting. So, one thing interests me (to hijack my own thread...heh), that is, ``calls are marshaled to that thread..." This confuses me. So, perhaps a thread coming into COM looking to get something done (open a OpenFile Dialog or something) comes in, COM looks at him and decides he's STA. So, does COM hijack that thread or create a new thread? How can COM marshal calls on a thread that it doesn't own? Or, is this always done in a message pump? Perhaps you could point me to an article on this. Your answer is excellent, rating 5. Thanks.
In Christ, Aaron Laws http://ProCure.com
-
Thanks for clarifying that. I have known this, but it faded away a bit, and that fact confirms your final statement, it not being very relevant for a pure .NET application, which is what I do most of the time. I do recall threads could choose their STA/MTA inclination, but only once. What isn't clear to me (I should look it up actually) is the consequences of the STA/MTA choice made on static Main(); does that only affect the main thread, or does it set the default for all threads? :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
Mr. Pattyn, My experience thus far has been that the main method only sets the initial thread's apartment model, not the default for future threads.
In Christ, Aaron Laws http://ProCure.com
