Game Development Reference
In-Depth Information
{
++dwCount;
{
// Request ownership of critical section.
ScopedCriticalSection locker(g_criticalSection);
++g_ProtectedTotal;
}
}
Succeed();
}
The thread process is defined by
VThreadProc()
. Two static members of this class
are the variable the process is going to increment and the critical section that will be
shared between multiple instances of the real-time process. Just before the thread
process returns,
Succeed()
is called to tell the Process Manager to clean up the pro-
cess and launch any dependent processes.
As it turns out, you instantiate a real-time process in exactly the same way you do a
cooperative process:
for( i=0; i < 20; i++ )
{
shared_ptr<Process> proc(GCC_NEW ProtectedProcess(100000));
procMgr->AttachProcess(proc);
}
The above example instantiates 20 processes that will each increment the global vari-
able 100,000 times. The use of the critical sections ensures that when all the processes
are complete, the global variable will be set to exactly 2,000,000.
There
'
s probably no system in the GameCode4 architecture that uses STL containers
more than the
EventManager
class. Given that STL containers aren
'
t thread safe by
themselves, there
s one of two things that can be done.
We could make all the containers in the Event Manager thread safe. This includes
two
std::map
objects, three
std::pair
objects, and two
std::list
objects.
This would be a horrible idea, since the vast majority of the event system is accessed
only by the main process and doesn
'
'
t need to be thread safe. A better idea would be
to create a single, thread-safe container that could accept events that were sent by
real-time processes. When the event system runs its
VUpdate()
method, it can
empty this queue in a thread-safe manner and handle the events sent by real-time
processes along with the rest.
