Threading is Hurting My Brain

Started by Thorin, September 14, 2010, 11:33:32 AM

Previous topic - Next topic

Tom

Oy, so MS's api creates and fires off a new thread per event? or just one per device? Personally I'd prefer the latter, but I'd prefer a single thread for all devices, but if MS doesn't "allow" that, well that just sucks.
<Zapata Prime> I smell Stanley... And he smells good!!!

Mr. Analog

Quote from: Thorin on September 16, 2010, 04:06:26 PM
See, that's why I said it's hurting my brain...  Even when you think you have things figured out, there's still that lurking uncertainty.  Threading is so cool yet so hard to do 100% right.  It's almost like real security, in that sense.

Your description of using asynchronous threads makes me think of the discussion with That Guy At Questionmark about CQRS (Command Query Response Segregation) where basically there are asynchronous updates to the database that do not need to return any data.  And that hurts my brain, too.

Yep, the main thing I see wrong with most multi-threaded implementations is that the light bulb will go "halfway" on that says "I can run things in parallel" but the other half that says "those things have dependencies that make them synchronous with serious locking ramifications no matter how badly I want them to be otherwise" never lights up.

I could go on and on about the app I work on in very loose terms with great examples of this kind of thinking that got halfway there (but I won't bore/frighten you).

I've actually taken a look back at my own asynchronous multithreaded implementations (specifically AJAX stuff) and seen various flaws and performance bottlenecks that would have been caused from me not considering the full scope of what I was doing.

Part of it is knowing how the tech works, for example:

The .NET Framework has a memory limit of 2 GB (for CLR objects), Web Services are by design multi-threaded, they have a pool of 25 worker threads and will split off each incoming request into it's own process, if you are pushing ~80 MB per request into memory the service can handle 25 simultaneous calls before the .NET Framework will run out of available memory. With all the CLR object memory committed no other .NET code can allocate memory until what's "in use" is deallocated by the garbage collector, but get this, if there are still incoming service requests the thread pool will lock and start committing object data to L2 memory and will never be cleaned up by the garbage collection! You're only option is to recycle ASP.NET manually (YIKES!!).

Now, obviously that's an unlikely example for a single web service, but it's easy to imagine this happening with many web services all consuming/using memory as small as a few kilobytes to several megs on each request and it doesn't take a lot of guessing to know what happens to async processes and impatient users when there is no available memory!

So err, I guess I *did* throw in a generalized example from work, this actually used to happen all the time last year (and still does when things get really busy). For us the primary culprit was a known memory leak in the XML libraries used in .NET 1.1 that started to poison the well at about 6 AM every day causing what I described above to happen artificially BUT it sure made me think about what was really going on in a holistic way.

CRAY-ZEE!

I swear I learn so much from these crippled/broken apps!
By Grabthar's Hammer

Tom

#17
Theres a reason my silly little game's server isn't threaded (yet). Right now, if I can get away with it, it'll stick being a single process per node. but the nodes can all talk to each other. And more than one can be running on the same host, and listen on the same port so that gets me multi core support ;D

If I do end up having to add a thread or two to the server, it'll be in the actual game logic handling. the ai or move validation code might start causing too much latency on larger boards, having the ai or validation code in a separate thread would help aliviate that. And I could potentially use "rwlocks" which are fancy locking primitives that let multiple threads read so long as no-one is writing, so only when something goes to modify game state should there be any locking. And since its a turn based board game, in any modern computer's eyes, it won't happen very often per game.

[Mod: Moved post as it was in the wrong topic]
<Zapata Prime> I smell Stanley... And he smells good!!!