2006-03-27

 

Threading woes

Getting multithreaded code right is just so damn hard. Reasoning about it's behavior or correctness is even harder! We'll be doomed until we get something of much higher level than threads and locks.

Why I'm writing this? Because my head hurts from trying to make the renderer run in one thread, and the containing application in the other. With added spice that most (win32) GUI stuff must happen in one thread, OpenGL contexts can only be active in a single thread, simple functions must be split into complex chains of inter-threading calls, etc. etc. The result is a mess that nobody can understand.

I hope I'm not missing something obvious (well, aside from the suggestion "just don't use threads").

# posted by NeARAZ @ 11:20
Comments
Have you tried writing 'retained' mode renderer instead - when application pushes the commands into the queue(/ring) for dx/ogl renderer running on the other thread. Basically the same way as driver does ;)

Or I'm missing smthng?
# posted by Blogger ReJ : 16:54  
My goal right now is not making a multithreaded renderer, just running the whole damn thing in a separate thread from the main (enclosing) app. This main app does not do much, but handles win32 UI stuff and, well, stuff...

The main point I'm bitching about: consider in a single threaded case, a function like ToggleFullscreen(). Now, if you're in multithreaded world, this turns into a monster because some things must be done in one thread, some in the other; in particular order blah blah.

It's not SO hard on absolute scale, but compared to simplicity of a single-threaded code, it's still an order of magnitude more complex... :(
# posted by Blogger NeARAZ : 10:04  
Sounds like you can't actually just have two threads, you needs at least three, with one being the supervisor thread.
# posted by Anonymous Anonymous : 01:28  
nearaz: "some things must be done in one thread, some in the other; in particular order blah blah."

doesn't that mean, that you have potentially bad functionality 'cut' among the threads? (I mean having words like 'thread' and 'particular order' in the same sentence - at least in this particular case)

For example, what is the purpose of having DX/OGL run in the separate thread from UI? Unless they're 2 separate windows. But even in that case you probably should treat them as a more separate processes and just send commands (UI commands in this case, instead of the rendering commands, which I suggested before ;) )

What I'm saying - if you can keep state of each thread totally encapsulated (in case of ToggleFullscreen() only one thread should bother, and maybe he will kickstart some other threads like res. loaders later on) and implement retained communication between them (one way preferably ;) )- that's a benefit. Otherwise you at risk running your threads in a lockstep which kinda kills the threading benefit.

But of course there are tons of special cases :)
# posted by Blogger ReJ : 12:03  
Well... it's for the plugins that use GL and run in the browser. I guess you could call that a special case pretty easily :)

And pretty much everything is fine, and separate threads are better than single thread. I was mostly bithing about the complexity of setup/shutdown and then some special events code.

Ok, enough whining. Consider the case closed.
# posted by Blogger NeARAZ : 14:30  
Post a Comment

<< Home