I have a game engine which used Directx 9 for rendering. I would like to be able to load sprite graphics in whilst the main update and render loop executes. Currently the engine has one main update and render loop so any loading done in this will pause the main loop whilst the graphics load.
I was looking at POSIX threads to do this. I have created the thread function and included mutex locks but the code crashes when its ran.
Here is the thread function:
void GameApp::InternalThreadEntry()
{
pthread_mutex_lock (&mutex);
for(int i = 0; i < MAX_NUMBER; i++)
{
test_loader_sprites[i].loadImage(window1,"Test_Image.tga");
}
has_finishd_loading = true;
pthread_mutex_unlock (&mutex);
}
The Code crashes in my engines render function. Im sure this is because the directx device, which is a member of the window1 instance, is accessed for loading by the thread whilst the main application accesses it for rendering.
Could you shed a little light on where im going wrong. Im new to using threads.
All the best,
Martin
Threading is often a wolf in sheeps clothing. It looks to solve so many problems, but in reality can cause so many more than they solve. Fortunately you have what many would believe a valid scenario to use an additional thread.
Having written a similar loader myself a while back, your problem looks to indeed be that you are accessing Window1 while its in use elsewhere. Basically, does your main thread do anything with Window1 while the thread would be running. If so then that would indicate it to be the problem.
The solution I found was to properly separate out data storage from the renderer. You can load in the data to a store in a thread. Once that has done, pass that information in the store to the main thread at the end of the thread (or move it directly in the main thread later). This avoids dependency on your Window1 object within the thread.
It would be a good idea to do some further reading on threads before embarking on a larger scale scenario it sounds you are working on. Working with threads is one of the more fiddly and complicated areas of software design, and from experience you can't learn them well enough.
Related
I can't seem to find a good answer to this:
I'm making a game, and I want the logic loop to be separate from the graphics loop. In other words I want the game to go through a loop every X milliseconds regardless of how many frames/second it is displaying.
Obviously they will both be sharing a lot of variables, so I can't have a thread/timer passing one variable back and forth... I'm basically just looking for a way to have a timer in the background that every X milliseconds sends out a flag to execute the logic loop, regardless of where the graphics loop is.
I'm open to any suggestions. It seems like the best option is to have 2 threads, but I'm not sure what the best way to communicate between them is, without constantly synchronizing large amounts of data.
You can very well do multithreading by having your "world view" exchanged every tick. So here is how it works:
Your current world view is pointed to by a single smart pointer and is read only, so no locking is necessary.
Your logic creates your (first) world view, publishes it and schedules the renderer.
Your renderer grabs a copy of the pointer to your world view and renders it (remember, read-only)
In the meantime, your logic creates a new, slightly different world view.
When it's done it exchanges the pointer to the current world view, publishing it as the current one.
Even if the renderer is still busy with the old world view there is no locking necessary.
Eventually the renderer finishes rendering the (old) world. It grabs the new world view and starts another run.
In the meantime, ... (goto step 4)
The only locking you need is for the time when you publish or grab the pointer to the world. As an alternative you can do atomic exchange but then you have to make sure you use smart pointers that can do that.
Most toolkits have an event loop (built above some multiplexing syscall like poll(2) -or the obsolete select-...), e.g. GTK has g_application_run (which is above:) gtk_main which is built above Glib main event loop (which in fact does a poll or something similar). Likewise, Qt has QApplication and its exec methods.
Very often, you can register timers within the event loop. For GTK, use GTimers, g_timeout_add etc. For Qt learn about its timers.
Very often, you can also register some idle or background processing, which is one of your function which is started by the event loop after other events and timeouts have been processed. Your idle function is expected to run quickly (usually it does a small step of some computation in a few milliseconds, to keep the GUI responsive). For GTK, use g_idle_add etc. IIRC, in Qt you can use a timer with a 0 delay.
So you could code even a (conceptually) single threaded application, using timeouts and idle processing.
Of course, you could use multi-threading: generally the main thread is running the event loop, and other threads can do other things. You have synchronization issues. On POSIX systems, a nice synchronization trick could be to use a pipe(7) to self: you set up a pipe before running the event loop, and your computation threads may write a few bytes on it, while the main event loop is "listening" on it (with GTK, using g_source_add_poll or async IO or GUnixInputStream etc.., with Qt, using QSocketNotifier etc....). Then, in the input handler running in the main loop for that pipe, you could access traditional global data with mutexes etc...
Conceptually, read about continuations. It is a relevant notion.
You could have a Draw and Update Method attached to all your game components. That way you can set it that while your game is running the update is called and the draw is ignored or any combination of the two. It also has the benefit of keeping logic and graphics completely separate.
Couldn't you just have a draw method for each object that needs to be drawn and make them globals. Then just run your rendering thread with a sleep delay in it. As long as your rendering thread doesn't write any information to the globals you should be fine. Look up sfml to see an example of it in action.
If you are running on a unix system you could use usleep() however that is not available on windows so you might want to look here for alternatives.
I am doing some development trying out C++11 threads. I would like to run some code in an asynchronous thread and when that code is done I would like to run other code on the main thread But only when it's done!
This is because the things I would like to run async is loading OpenGL stuff, and it's a bit tricky with the OpenGL contexts when doing threads, as far as I know it's pretty much a don't run the same context in different threads.
However I would like to create a loader thread, which loads collada files and the time consuming stuff here really is to parse the file and set up the data and all of that I could (technically) do in a separate thread and then just do the opengl specific tasks on the main thread. (this is my initial thought and I might just be going at it the wrong way)..
So I am thinking that if I could detach one thread async to load up the collada file and fill the out the data, then once it's finished I'll invoke on the main thread to bind buffers, set up shaders and so on. I can do it without threads, but would be pretty smooth to load new data in the background without GL freaking out..
So I'll try to line up the steps I want to do:
Main thread goes around doing what it does...
Someone asks for a new mesh to be loaded
the mesh initialized by creating an async thread and loading inside it the collada data
meanwhile the main thread goes on doing it's stuff
once the collada loading is done the async thread informs the main thread that it wishes to do additional loading (i.e. setup buffers, and so on) ON main thread.
the setting up finishes and the mesh adds itself to a render queue
I do have all of it working synchronous and what I want is a way to do some things once the detached async thread finishes.
Any ideas or of course constructive criticism of my thinking here :P is greeted with a warm welcome! I might be thinking about it all the wrong way, I've been thinking about doing something like an observer pattern but I don't really know how to tackle it the best way. I wouldn't mind threading the OpenGL stuff, but it seem a bit like asking for trouble..
If I understood your use case correctly, then I think the std::async() function, started with the std::launch::async policy to make sure the operation is really started on another thread, does just what you want:
// Your function to be executed asynchronously
bool load_meshes();
// You can provide additional arguments if load_meshes accepts arguments
auto f = std::async(std::launch::async, load_meshes);
// Here, the main thread can just do what it has to do...
// ...and when it's finished, it synchronizes with the operation
// and retrieve its result (if any)
bool res = f.get(); // res will hold the return value of load_meshes,
// or this will throw an exception if one was
// thrown inside load_meshes()
if (res)
{
// ... and then it will go on doing the remaining stuff on the main thread
}
One tricky thing to be aware of here, is that you should always assign the return value of std::async() to some variable (of type std::future<T>), where T is the type returned by load_meshes(). Failing to do so will cause the main thread to wait until load_meshes() is finished (thus, it's as if the function was invoked in the main thread).
This concerns C++ (MinGW), Qt, Windows Vista:
all this while i's developing non-GUI applications in C++. Recently i decided to try a GUI one in Qt and am having some design issues.
Here's the problem:
step 1: Load and display a background gif Animation using QMovie...
step 2: process huge dump files (over 2GB's)....so when i reached step 2 expectedly my GUI froze..
i was using while(getline(inputFileStream,stringLine)) {...} so i placed QCoreApplication::processEvents(); inside the loop.
The application became really slow. So i placed a counter which only if it reaches a particular value will QCoreApplication::processEvents(); be executed.
Now the gif animation has become more like series of frames with visible transition from one to another.
Any faster triggering of processEvents() slows the application down (which anyway is nowhere near the non-GUI execution time).
As i see from Windows Task Manager one core has high utilization while other has low during the execution period.
So what approach should i take? Should i delve into mutithreading (i'v never used it before)?
Stripping down everything to explain the question the program looks like this:
class Animation;
class FileProcessing;
main(int argc,char** argv) {
QApplication* app=new QApplication(argc,argv);
QLabel* label1=new QLabel(...);
QLabel* label2=new QLabel(...);
Animation* objAnim=new Animation(...); //QMovie plays gif
objAnim->show();
//fileDialogs --> ask for files..this is modal so animation is fine till this point
FileProcessing* objFileProcessing=new FileProcessing(...);
objFileProcessing->processFiles(label1,label2); //process >2GB files
//in this i repeatedly call processEvents() as written above
//delete labels,objAnim and objFileProcessing;
delete app;
return 0;
}
It's time for you to grow some balls and learn how to use threads. The GUI freezes because it runs within the same thread as the functions that deal with those large files. If you separate these tasks to be executed in different threads, the GUI can continue to be useable.
Since you have an interested in Qt, I suggest reading about QThread:
An Introduction to QThreads
Starting Threads with QThread
How To Really, Truly Use QThreads; The Full Explanation
You need to use a separate thread for the processing step.
You can have the processing thread periodically check a cancellation status variable. Should the user wish to cancel, set the variable to true. The processing thread can then exit gracefully.
I have a Snake game in-development (up at https://github.com/RobotGymnast/Gingerbread/tree/eventThreaded). Initially, everything (graphics, events, game logic update, physics) were called from a "main" thread. Then I started multithreading (using boost threads). It's been pretty straightforward, but I recently split the graphics display logic into a new thread, which allocated the screen object in its local stack space. Then I split my event-detection and event-handling logic into a new thread. Then my screen stopped appearing. Judging by my command-line output, everything still worked fine, just the screen stopped appearing. It turned out it was hanging on my SDL_SetVideoMode() call.
I fixed this by allocating my screen object in the "main" thread, and passing in a reference to the graphics thread. For some reason, allocating the screen object in a new thread from the event logic was creating problems.
Since this fix, the event-detection and event-handling no longer works. The event checks are still being made, e.g. SDL_PollEvent(), but they're not picking up any events at all (keyboard, mouse, etc.).
My suspicion is that SDL might do some behind-the-scenes thread syncing, but I've been using boost threads. Could this be a problem? SDL threads are rather restrictive, and I'd rather not switch.
Anybody had this issue before? Any recommendations?
I'm not sure about SDL, but on several windowing subsystems (I believe on both X and Win32), you cannot modify ANYTHING related to a graphics object or widget, except from the thread which initially created that graphics object/widget.
It doesn't look like (to my limited 10 second google search) SDL abstracts that bit from you -- you'd need to only modify graphics related objects from the thread that created them. To do otherwise is to invite strange behavior.
Graphics display logic should almost always be in the main thread, due to some technical considerations on various platforms.
Similarly, the event handling (at least at the low level) should be in the main thread, as events can be posted to specific threads rather than processes.
For the most part I would recommend not calling any SDL functions from anything other than the main thread apart from ones that don't operate on shared state.
My program does file loading and memcpy'ing in the background while the screen is meant to be updated interactively. The idea is to have async loading of files the program will soon need so that they are ready to be used when the main thread needs them. However, the loads/copies don't seem to happen in parallel with the main thread. The main thread pauses during the loading and will often wait for all loads (can be up to 8 at once) to finish before the next iteration of the main thread's main loop.
I'm using Win32, so I'm using _beginthread for creating the file-loading/copying thread.
The worker thread function:
void fileLoadThreadFunc(void *arglist)
{
while(true)
{
// s_mutex keeps the list from being updated by the main thread
s_mutex.lock(); // uses WaitForSingleObject INFINITE
// s_filesToLoad is a list added to from the main thread
while (s_filesToLoad.size() == 0)
{
s_mutex.unlock();
Sleep(10);
s_mutex.lock();
}
loadObj *obj = s_filesToLoad[0];
s_filesToLoad.erase(s_filesToLoad.begin());
s_mutex.unlock();
obj->loadFileAndMemcpy();
}
}
main thread startup:
_beginThread(fileLoadThreadFunc, 0, NULL);
code in a class that the main thread uses to "kick" the thread for loading a file:
// I used the commented code to see if main thread was ever blocking
// but the PRINT never printed, so it looks like it never was waiting on the worker
//while(!s_mutex.lock(false))
//{
// PRINT(L"blocked! ");
//}
s_mutex.lock();
s_filesToLoad.push_back(this);
s_mutex.unlock();
Some more notes based on comments:
The loadFileAndMemcpy() function in the worker thread loads via Win32 ReadFile function - does this cause the main thread to block?
I reduced the worker thread priority to either THREAD_PRIORITY_BELOW_NORMAL and THREAD_PRIORITY_LOWEST, and that helps a bit, but when I move the mouse around to see how slowly it moves while the worker thread is working, the mouse "jumps" a bit (without lowering the priority, it was MUCH worse).
I am running on a Core 2 Duo, so I wouldn't expect to see any mouse lag at all.
Mutex code doesn't seem to be an issue since the "blocked!" never printed in my test code above.
I bumped the sleep up to 100ms, but even 1000ms doesn't seem to help as far as the mouse lag goes.
Data being loaded is tiny - 20k .png images (but they are 2048x2048).. they are small size since this is just test data, one single color in the image, so real data will be much larger.
You will have to show the code for the main thread to indicate how it is notified that it a file is loaded. Most likely the blocking issue is there. This is really a good case for using asynchronous I/O instead of threads if you can work it into your main loop. If nothing else you really need to use conditions or events. One to trigger the file reader thread that there is work to do, and another to signal the main thread a file has been loaded.
Edit: Alright, so this is a game, and you're polling to see if the file is done loading as part of the rendering loop. Here's what I would try: use ReadFileEx to initiate an overlapped read. This won't block. Then in your main loop you can check if the read is done by using one of the Wait functions with a zero timeout. This won't block either.
Not sure on your specific problem but you really should mutex-protect the size call as well.
void fileLoadThreadFunc(void *arglist) {
while (true) {
s_mutex.lock();
while (s_filesToLoad.size() == 0) {
s_mutex.unlock();
Sleep(10);
s_mutex.lock();
}
loadObj *obj = s_filesToLoad[0];
s_filesToLoad.erase(s_filesToLoad.begin());
s_mutex.unlock();
obj->loadFileAndMemcpy();
}
}
Now, examining your specific problem, I can see nothing wrong with the code you've provided. The main thread and file loader thread should quite happily run side-by-side if that mutex is the only contention between them.
I say that because there may be other points of contention, such as in the standard library, that your sample code doesn't show.
I'd write that loop this way, less locking unlock which could get messed up :P :
void fileLoadThreadFunc(void *arglist)
{
while(true)
{
loadObj *obj = NULL;
// protect all access to the vector
s_mutex.lock();
if(s_filesToLoad.size() != 0)
{
obj = s_filesToLoad[0];
s_filesToLoad.erase(s_filesToLoad.begin());
}
s_mutex.unlock();
if( obj != NULL )
obj->loadFileAndMemcpy();
else
Sleep(10);
}
}
MSDN on Synchronization
if you can consider open source options, Java has a blocking queue [link] as does Python [link]. This would reduce your code to (queue here is bound to load_fcn, i.e. using a closure)
def load_fcn():
while True:
queue.get().loadFileAndMemcpy()
threading.Thread(target=load_fcn).start()
Even though you're maybe not supposed to use them, python 3.0 threads have a _stop() function and python2.0 threads have a _Thread__stop function. You could also write a "None" value to the queue and check in load_fcn().
Also, search stackoverflow for "[python] gui" and "[subjective] [gui] [java]" if you wish.
Based on the information present at this point, my guess would be that something in handler for the file loading is interacting with your main loop. I do not know the libraries involved, but based on your description the file handler does something along the following lines:
Load raw binary data for a 20k file
Interpret the 20k as a PNG file
Load into a structure representing a 2048x2048 pixel image
The following possibilities come to mind regarding the libraries you use to achieve these steps:
Could it be that the memory allocation for the uncompressed image data is holding a lock that the main thread needs for any drawing / interactive operations it performs?
Could it be that a call that is responsible for translating the PNG data into pixels actually holds a low-level game library lock that adversely interacts with your main thread?
The best way to get some more information would be to try and model the activity of your file loader handler without using the current code in it... write a routine yourself that allocates the right size of memory block and performs some processing that turns 20k of source data into a structure the size of the target block... then add further logic to it one bit at a time until you narrow down when performance crashes to isolate the culprit.
I think that your problem lies with access to the FilesToLoad object.
As I see it this object is locked by your thread when the it is actually processing it (which is every 10ms according to your code) and by your main thread as it is trying to update the list. This probably means that your main thread is waiting for a while to access it and/or the OS sorts out any race situations that may occur.
I would would suggest that you either start up a worker thread just to load a file when you as you want it, setting a semaphore (or even a bool value) to show when it has completed or use _beginthreadex and create a suspended thread for each file and then synchronise them so that as each one completes the next in line is resumed.
If you want a thread to run permenently in the background erasing and loading files then you could always have it process it's own message queue and use windows messaging to pass data back and forth. This saves a lot of heartache regarding thread locking and race condition avoidance.