You know, I don''t think there are any tutorials on using threads for resource loading on the site... there''s this article about the Win32 file functions, which is where to start. You could use those in a worker thread.

You can also use asyncronous IO, and a worker thread to manage the IO request. The game thread then makes a request to the worker thread, and polls something to determine when the data is ready. But that''s a bit more complicated.

With a game running flat-out - there is no background/idle time.

Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

"What I see is a system that _could do anything - but currently does nothing !" - Anonymous CEO

Worker threads (basically what you are talking about) can be very useful, especially when you have a UI that you want to remain responsive while you do work in the background (or something along those lines). You need to be very careful when using threads. Here are a few tips:

1. If you have shared data that more than one thread can access at a time, then you need to synchronize access to that data. There are many ways to do this. CRITICAL_SECTIONs are one way, Events, Mutexes, Semaphores, etc are other ways. The Interlocked* functions are excellent for simple things. If you don''t protect shared data, then you can run into data corruption very easily.

2. Don''t ever ever ever ever ever ever ever use TerminateThread(). If you do, don''t be surprised if you get random AVs, etc in your process.

3. Have a way to communicate with your worker thread(s). This can be using Events to signal specific states (like "time to shutdown" or "starting processing", etc). Or you can use message-only windows, and the Win32 window messaging APIs to send messages between your two (or more) threads. You can also create your own messaging/command system.

4. Don''t use too many threads. Each thread takes up system resources (like stack space for example). Each non-sleeping thread consumes time slices, and requires a context switch to occur every time a thread is switched to by the OS. Context switches can be very expensive, especially when they occur too often.

5. Excessive thread synchronization can hurt your performance (context switches are one reason, contention for shared resources is another). One way to maximize the benefits of threads is to partition the work that a thread needs to do. The best case scenario is to have a data set that a thread can work on completely autonomously (the fire-and-forget methodology). Performance starts to degrade if you have, for example, a queue with work items in it, that each thread has to access to get it''s next piece of work. If the scope of the work is known up front, then you can divide that work by the number of threads, and give each "partition" to each thread and let them go.

6. I''m sure I can think of more.. but it''s late and I''m tired =).



-Brannon

Hmm, last time I installed a Linux distro you still didn''t get thread support by default (but that was a while ago). There is a library for Linux called linuxthreads that I have used, and it''s decent .. but after programming with the Win32 thread APIs, you will think linuxthreads is archaic (with all due respect to the linuxthreads author, it''s an implementation of posix threads, so blame the posix folks).

If you don''t want to use SDL, you can look for another library that provides a platform independent thread library (you might even be able to find a posix threads implementation for Win32), or you can write your own. If you are just doing simple worker threads to do background level loading, etc.. then it shouldn''t be too hard to create a crossplatform thread library.



-Brannon