|
I must have missed it or forgot. Sorry. My memory isn't what it used to be. No offense.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: No offense. Don't worry... I was just bugging you a bit
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Well well. Let's see if we can get a Protector's account closed for trolling!
|
|
|
|
|
You are laughing, but... do you really consider that trolling?
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Mild trolling, sure. Which is what makes it so funny.
|
|
|
|
|
mmm... then I suppose it is a definition thing.
For me trolling is negative, done to harm or to get the other part mad on purpose.
This was more a joke, since I had no bad intentions at all, I do respect the code witch and I am not that kind of user.
Ah... and BTW it is true, I told about that JSOP's article here[^].
Just in case you think the trolling part was to lie about it
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
When you said you were just bugging Honey a bit, I thought you meant that you made the whole thing up! I'd call that mild trolling, to get a reaction, but it shouldn't bother anyone.
|
|
|
|
|
Greg Utas wrote: I thought you meant that you made the whole thing up! Nope, I didn't.
The bugging was the "I told you so", knowing that my comment went undernoticed. If not... I would have got a comment to that.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Yes, I see that now, so it wasn't trolling in any way.
|
|
|
|
|
YOU TERRIBLE TROLL!!!!
Real programmers use butterflies
|
|
|
|
|
I just read it. It's interesting that you managed your own threadpool. The more I try to work with the built in one, the more i want to go back to my own thread pool management like i was doing before. I'll take a look at that SmartThreadPool class to see how it works. I'm interested in that.
I'm using Invoke/BeginInvoke already for my UI updates, but that's not the focus of my project, which relies on message queuing.
The thing I wonder about, is since Task.Run() uses ThreadPool , if I won't have to somehow intercept or wrap it so that it uses mine. I don't know if that's possible.
This was actually easier to do without having to consider Task or ThreadPool . Funny that.
Real programmers use butterflies
|
|
|
|
|
I think TPL manages the thread pool for you.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I figured out some more stuff. Instead of using my own thread pool, I simply changed the way Task items get scheduled, so it will queue items after it exceeds my own quota. That way it still uses the system threadpool but in a way that makes sense. the relevant class is under the Tasks namespace and it's called TaskScheduler . It's kinda neat, but not very well documented.
Real programmers use butterflies
|
|
|
|
|
|
Thanks!
This is how i got around it - i can still use it, but i can throttle the number of concurrent tasks.
Customizing the TaskScheduler: Queue Your Task Work Items to Run When You Want Them To[^]
Seems not so popular, maybe because i ripped a lot of code out of a microsoft example in their docs, but unlike them i explained it (and i modified it)
ETA: The advantage over using a custom thread pool is you can still use tasks with it. To use a custom threadpool like stephens, i'd still need a custom task scheduler similar to what i wrote above to launch tasks on that threadpool
Real programmers use butterflies
|
|
|
|
|
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
|
|
|
|