in reply to Re^6: Threads + OpenGL act weirdly?
in thread Threads + OpenGL act weirdly?

and a matter of a few hours of testing to tweak the balance of "cede"s inside the synch routine and in the normal loop to match up nicely

That is the problem with cooperative threading/event systems: balancing the needs of the various concurrent processes so that the high speed events are processed in a timely fashion without breaking up the long running parts in to such iddy biddy chunks that nothing ever gets done. And the more concurrency you need the harder that balancing act becomes.

But the very worst part is that just as soon as you get everything balanced and cooperating nicely, the requirements change--a new one is added or an existing one is no longer required and you have to start the whole process over from scratch. I remember one such system in a production environment that processed the same three dummy datafiles over and over hundreds of time every day--in each of 300 stores--for years, simply because it was easier, than trying to remove that processing and re-balance the system.

The users could not believe how much more responsive the systems were when we replaced the old, cooperative DOS-based system with one that multi-tasked under OS/2. A part of the change was because of newer faster hardware, but most of it came simply because 40% of the cpu's time was no longer being used to 'busy work', processing files that were no longer required, but too difficult and risky to consider removing. We calculated that over the preceding 4 years, those same three files had been pointlesly reprocessed just short of a billion times!

The reason preemptive multi-tasking predominates, is because you write simple, linear flows for each task and let the scheduler take care of mixing them up. When an old task is no longer needed, or a new task it required, you just add or remove it. You don't have to go messing with everything else in the system to restore the balance.

Anyway, I'm glad you found a solution that works for you. As an aside, if the code isn't proprietary, I'd love to get a copy and see if it's possible to do what you need with threading?

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^8: Threads + OpenGL act weirdly?
by Xenofur (Monk) on Sep 29, 2008 at 00:00 UTC
    What you write about is exactly what i encountered. Previously i didn't have an idle callback in the glut mainloop registered, and as such the program was only using cpu when it was actually doing something. However now i'm forced to have the idle callback go cede(); all the time so the background synch loop doesn't stall. But i'm fine with that honestly, OpenGL applications normally run at full tilt at all times anyhow.

    I'd LOVE to use proper threading, but i'm afraid i have no clue how to accomplish that when i'd need to share a three-dimensional as well as 2 four-dimensional arrays with the background thread as well.

    As for the code, it is entirely public domain and hosted here: http://code.google.com/p/dwarvis/
    You can either grab /trunk/lifevis from the svn, or get a prepared package from here: http://dwarvis.googlecode.com/svn/latest_downloads/lifevis.rar (Note that there are a bunch of files in the prog directory, like a flowchart .dia (out-dated and uncomplete, but still mostly relevant) and some other things.)
    Also know that you will need to have the freeware game Dwarf Fortress (http://bay12games.com/dwarves/) loaded with a world created, and a fortress embarked and open on your screen before lifevis will do anything useful.

    Aside from that, i was thinking about posting in Meditations later on to see if i could get some advice on the overall thing, have people weigh in on what parts could be useful for others as CPAN modules, etc. As such, any and all comments are welcomed. :)

    I should also note: I'm not always going the "proper" way in this. It is very much unfinished still and i don't want to burn myself out on learning overly complex modules and instead push on with implementation. So i may in the future and have already in the past ignore modules that might be useful, but come with either extremely complex usage patterns or documentation that assumes one already knows how the module works.
[reply]
[d/l]

In Section Seekers of Perl Wisdom