|
Maybe it's just my NIH proclivity, but following all this just reinforces why I have no time for languages and frameworks that provide higher level threading abstractions. They're usually beyond clueless. Hell, even most of the O/S's are clueless.
|
|
|
|
|
I usually don't care for it either, although using async/await and letting compiler build the necessary state machine to make it work is pretty cool
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: I expect more like a few at most for most applications, and a well written app shouldn't have more CPU bound operations than there are CPU cores (or hardware threads) when possible, so why so many?
Threads fortunately aren't limited to the amount of CPU cores; that'd be quite unusable. Instead of having a thread for each core, we bind them to functionality that is either or not suspended.
Even in the days of single-core desktops my WinForm apps would spawn multiple threads (as do most applications). If the user would click anything, I'd spawn a thread so that the UI would stay nicely responsive and drawing, and the user would have immediate feedback on his action (as opposed to SQL Server update which doesn't show a window and you have to launch taskman just to check whether it is still running).
Also take into account that the amount of threads in the pool might not be "per application".
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
The docs say it's per process, and what I'm saying has to do with performance.
Sure if you're UI thread is being tied up, move some of that to background work, but the bottom line is if you've got more threads than hardware to run them you are wasting CPU time context switching.
My statement again, was purely about designing an app for maximum throughput.
I guess there would be reasons to spawn more threads than that, but all you're doing at that point IMO is using threads as an abstraction.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: The docs say it's per process, and what I'm saying has to do with performance.
If each .NET app would spawn 2k threads, you'd notice it.
honey the codewitch wrote: My statement again, was purely about designing an app for maximum throughput.
I guess there would be reasons to spawn more threads than that, but all you're doing at that point IMO is using threads as an abstraction.
Most applications have a UI, and events; rarely do I see a application where only processing is involved; in which case you break up the application to run decentralized, instead of mucking with threads.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I said in the article i wrote about this (and perhaps in the OC, i don't remember) that the threads might be cutouts.
I'm simply reporting the value of GetAvaialableThreads() vs GetMinThreads() and GetMaxThreads()
If Microsoft's thread pool is lying to me, that's on them.
Real programmers use butterflies
|
|
|
|
|
I don't think it is lying, just missing context.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
The UI loop is typically spun on a single thread, with events firing out of the loop it's spinning. I'm not sure if you're trying to imply they're typically firing those events off of other threads, but in my experience, they don't.
Real programmers use butterflies
|
|
|
|
|
I do; as explained, for almost every user action. There was an example-project from MS that implemented MSN Messenger in .NET, and it did the same; almost everything that took longer than 250ms was on a background thread.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
250ms is a quarter of a second, so that's "long running" in my book, in that you can't tie up the UI thread for that long.
I guess if you're doing a ton of those all the time, you may be spawning more threads to handle it, but I don't see how being able to move the window around even as the UI is lagging its update by 250ms or more all the time is much of an improvement.
Personally, I don't know enough about the app to say otherwise, but if i found i was running in to that I'd look at my design.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: I guess if you're doing a ton of those all the time, you may be spawning more threads to handle it, but I don't see how being able to move the window around even as the UI is lagging its update by 250ms or more all the time is much of an improvement.
If the UI isn't updated for some time, Windows gives this nice option to close your non-responsive application. Also, usually got a thread for loading grids in the background, synchronizing a progress-bar at the same time. Gives a much better user experience than normal databinding.
MSDN states that since .NET 4, it "depends" on multiple factors. MS being helpful as always, but at least it proves Google wrong. Querying the values in a new project yields below results on my machine;
GetMinThreads - workerThreads 6, completionPortThreads 6
GetMaxThreads - workerThreads 2047, completionPortThreads 1000
GetAvailableThreads - workerThreads 2047, completionPortThreads 1000 Somehow I doubt that Max and Available are the same, but that's indeed what the framework reports.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Those are the numbers I get too. The minimums are reasonable, but the maximums are ridiculous, IMNSHO.
The only reason I can think of for microsoft to set those figures so high is to virtually guarantee that CPU bound "async" tasks are never completed synchronously. That doesn't seem right to me though. Like I said, I miss working at Microsoft, where there was someone I could shoot an email to who might know and respond.
Real programmers use butterflies
|
|
|
|
|
It may be that the "max" is equal to "available"; doesn't mean "active", but that'd be horrendously confusing.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
especially considering I am using GetAvaialableThreads() and it's the same count as GetMaxThreads() 
Stephen Toub, who I trust as an expert, has been relying on his own thread pool implementation in .NET for years, and the rant in the OP i think is one of the reasons.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: The docs say it's per process,
And how many? Do you have a link? Google claims this;
What is the default value for thread pool size?
5
The Max Thread Pool Size parameter specifies the maximum number of simultaneous requests the server can handle. The default value is 5. When the server has reached the limit or request threads, it defers processing new requests until the number of active requests drops below the maximum amount.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
That may be what google reports, but it's not what my actual code reports.
ETA: Are you sure that's talking about the .NET ThreadPool class?
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: ETA: Are you sure that's talking about the .NET ThreadPool class?
Not quite, because I can't find the equivalent on MSDN, which I'd expect to be correct. It implies the .NET threadpool, since the other answers are about it too.
honey the codewitch wrote: That may be what google reports, but it's not what my actual code reports.
I seriously dislike it when code and documentation don't come with the same answer. What I did find was another "max";
MSDN claims: There is one default thread pool per process, including Svchost.exe. By default, each thread pool has a maximum of 500 worker threads.
Now, a maximum of 500 sounds reasonable, given that the average UI only uses 20 or so backgroundworkers, and perhaps 2 to 4 threads for processing data/async reading/writing.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Yeah 500 would be, just because you have all kinds of library code and framework code running along with your app code, and they need threads too.
When I design an app for throughput I do try to take that into consideration but it can only be found with profiling. Consequently, for me to know how many long running tasks i should be serving varies.
But otherwise I try to design as if I'm the only app running. The reason is if it's about moving and chunking bits fast, it's either a game, or some heavy app, or a server of some sort although those are mostly I/O bound except for things like game servers. But either way, the end user probably is aware of its requirements and will not expect it to run well with lots of other stuff going on.
The OS does a good job of scheduling its own threads so in practice I ignore OS stuff. It tends to background itself when an app is cranking anyway.
This is all just experiential. I used to write a lot of ISAPI code for work, and I had to think about what my threads were doing, and manage a "proper" thread pool. By "proper" I mean, it was directly tied to how many incoming I/O bound requests it was expected to serve - so it's a bit of a different animal but with similar concepts to say a game, or a computationally intensive app, like an mpeg encoder in that you head to very careful with how you were using the threads you had.
If I was writing something I/O bound and CPU bound, like a video player, i still wouldn't need a lot of threads. In the neighborhood of 3 depending on the system - one for I/O (so it's not tying up CPU), one for decoding (CPU bound), and one for rendering - usually tied with UI (CPU and/or GPU bound).
I guess thinking about it, I haven't run into a lot of middle ground with respect to app performance. Usually my apps either have to be casual about threading and simply reserve them for things that would lock up the UI, or they have to go full bore and do as much work as they can in the time given.
Even my parser generators were casual, despite sometimes being very long running - the LALR algorithm for example, is murder on the CPU and is resistant to being parallelized.
So maybe it's a dearth of experience on my part, wherein I would need more a "medium" app which might consistently need a lot of threads due to executing a lot of short lived but still too long for the UI tasks. I can imagine scenarios, but nothing not contrived seeming. Again, perhaps my own tunnel vision due to not finding one I've had to write.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: Yeah 500 would be
As long as it doesn't start all 500 in the pool for each proces. Would explain though why the performance of my modern machine can't keep up with the UI of a Commodore Amiga. By the time the SQL Server upgrade UI appears, I clicked on the icon 10 times to "start" the damn application. Older machines give instant feedback in the UI, yet the modern ones need a few seconds to load their libraries and put up a "loading" screen.
honey the codewitch wrote: But otherwise I try to design as if I'm the only app running.
Haha, very different environments and designs  If you are the only app running, or have a dedicated machine, then it'd be wasteful to not use every resource there is. I usually have to assume that the user has at least one instance open of every Office-application, a mail-client, an IM client, a ton of browsers, with the user expecting a smooth experience even if they load half a gigabyte of crap into a grid.
honey the codewitch wrote: which might consistently need a lot of threads due to executing a lot of short lived but still too long for the UI tasks. I can imagine scenarios, but nothing not contrived seeming.
Not just short lived; any communication using TCP, or any disk-operation, I start a backgroundworker. There's quite the amount of "professionals" that read/write in a UI-event (on mouse click or whatever), blocking the UI and making you go through all the forms' events just to get an idea of the flow.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: any communication using TCP, or any disk-operation, I start a backgroundworker.
That's an I/O bound thread, not a CPU bound thread. I'm purely talking about CPU bound worker threads here.
I/O bound threads follow different rules because they spend most of their time asleep waiting for input.
ETA: I think the context got lost in the fray, but in OP, I'm talking about CPU bound worker threads. I'm not talking about I/O bound threads. You may have many more of those than you have cores. The threadpool keeps a separate pool for those.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: That's an I/O bound thread, not a CPU bound thread. I'm purely talking about CPU bound worker threads here.
I/O bound threads follow different rules because they spend most of their time asleep waiting for input.
I don't tell the BGW what kind of thread it is (except that it runs in the background, so shouldn't stop a shutdown of Windows). Not sure the ThreadPool knows that difference either.
Unless you talk about design; if you only mean generic threads meant to do processing and nothing else, then yes. Not my forte to do threads that only process (like a parser, or an Isapi-worker without UI). I just see the term "threads" and go "I create a shitload of them". Lots of apps do (some excessive, my dear Chrome), and they have little cost. Can't imagine creating over 2k threads in Delphi, just to pool them "in case".
Threading is exotic to most, and I'm talking to someone who knows his fibers (without fiberpool). For processing, my main focus is on giving the user feedback, and a time-guestimate. (Number of items existing-number of items processed) per second. So clients like me as much as they like the estimate of the copy-dialogue of Explorer.
So, this thread doesn't involve me at all, even despite it being my favorite subject? 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
The .NET threadpool class at least, does indeed know the difference. It maintains two pools even - one for CPU bound threads, and one for IO bound threads. I'm not sure your background worker would know the difference, but if it was designed for just one, I'd bet it was designed primarily for I/O bound ops.
CPU bound ops just aren't as common I think?, not that they are uncommon. It's just weird that the .NET threadpool sets the available and max for CPU bound threads to 2047 per process. That's not I/O threads - which as i said, have their own pool
A thread doesn't know if it's I/O bound or CPU bound. How it works is what makes it one or the other. It would have to understand its own code to know what it was. But basically I/O bound threads sleep like cats. The wake up when there's reason
But the reason to treat them separate at least in the .NET realm is that the tasks are set up to be optimized for one style over another and giving it the hint as to what kind of work it's doing helps for performance. The other issue is a design one. Again, CPU bound work needs hardware to run on or it's just mashing the scheduler if it has to share time. That's fine, to a degree, but CPU bound threads should be considered carefully in an application.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: It maintains two pools even
It's not named "TwoPools". And the BGW will prolly default to IO, since that's its most used pattern. Not that much people doing pure processing of data.
honey the codewitch wrote: A thread doesn't know if it's I/O bound or CPU bound.
So how would the framework know? For most of the crap I spawn it wouldn't make much difference, but it sounds like it is important to distinguish between them.
honey the codewitch wrote: But basically I/O bound threads sleep like cats
36 hrs per 24 hrs day. Not sure if Goedzo is awake when eating.
honey the codewitch wrote: but CPU bound threads should be considered carefully in an application.
The stuff drivers are made of? I don't know the difference; there's a pool and I draw upon it. If you need an article-idea, then this would confuse the hell out of people and get you some more downvotes
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: It's not named "TwoPools".
What's in a name? Try calling GetMaxThreads() or GetAvailableThreads() and they each return two values.
Eddy Vluggen wrote: So how would the framework know?
Because you tell it when you call QueueUserWorkItem() you're using a CPU bound thread - or at least one from the pool intended for that. When you use any of the items that use IO completion ports (like file or socket operations) .NET runs those on I/O threads for you.
multithreading - Simple description of worker and I/O threads in .NET - Stack Overflow[^]
Maybe that will help.
Eddy Vluggen wrote: The stuff drivers are made of?
No just the stuff you're running the processor ragged with when you call QueueUserWorkItem(). I'm not counting threads that spend most of their time sleeping.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: What's in a name? Try calling GetMaxThreads() or GetAvailableThreads() and they each return two values.
From experimenting, they look the same; the max is always available. Would be sick if max equals allocated, but docs don't give a hint of that.
honey the codewitch wrote: Because you tell it when you call QueueUserWorkItem()
I just create new BGW.
honey the codewitch wrote: Maybe that will help.
I'll queue it, currently sleepdrunk. Third day, so not a problem yet. Not much hallucinations until day five.
"Even this, shall pass away". Thread carefully in answering.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
