Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
Sponsored Feature: How to Start a Multi-Threading Relationship
View All     RSS
July 11, 2020
arrowPress Releases
July 11, 2020
Games Press
View All     RSS







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Sponsored Feature: How to Start a Multi-Threading Relationship


December 22, 2008 Article Start Previous Page 3 of 3
 

If you only need to see if a thread has finished processing, event handles are the best way to go about it. The FFT example given previously is perfect for this synchronization setup. Here is some pseudo-code that offers a solid way to ensure that data is being used only when the FFT thread has finished it.

HANDLE hFFTFinished;
HANDLE hFFTStart;

void FFT()
{
for(;;)
{
//Wait until the main thread signals this thread for analysis
WaitForSingleObject(hFFTStart, INFINITE);
ResetEvent(hFFTStart); //Reset the start event
//Run FFT and analyze data
SetEvent(hFFTFinished); //Signal that the analysis is finished
}
}

void Render()
{
//WaitForSingleObject with the second parameter 0 will check the
//handle and return the status immediately without waiting
if(TRUE == WaitForSingleObject(hFFTFinished, 0))
{
//Copy and render with new data
ResetEvent(hFFTFinished); //Reset the finished event
SetEvent(hFFTStart); //Set start event so FFT can analyze again
}
else
{
//Render with old data
}
}

By calling WaitForSingleObject with 0 as the second parameter (the second parameter is the amount in milliseconds that the wait should . . . wait), the function checks the status of the event, returning TRUE if it has been signaled and FALALSE if it has not.

If it has been signaled as complete, the main thread renders with the new data, resets hFFTFinished with ResetEvent, and then the hFFTStart handle is signaled to run another FFT analysis. This setup is a very efficient and extremely secure way to do two-way communication between two threads.

When you need exclusive access to data, such as when a thread will adjust memory that is to be used by another thread, then critical sections are the way to go. As pointed out above, without synchronization the UpdateBullet function could cause a memory fault if it isn't synchronized. So how do we fix this? Let's watch!

CRITICAL_SECTION bulletSection;

Bullet** pBullets;

void UpdateBullets()
{
//Loop forever, update constantly
for(;;)
{
EnterCriticalSection(&bulletSection);
for(int i = 0; i < numBullets; i++)
{
if(TRUE == isHittingSomething(pBullet))
{
//Destroy the bullet, free memory
}
Else
{
//Update bullet information
}
}
LeaveCriticalSection(&bulletSection);
}
}

void Render()
{
EnterCriticalSection(&bulletSection);
//Render the bullets
LeaveCriticalSection(&bulletSection);
}

Now, this setup ensures that when data is used for rendering it isn't being freed. Upon entering the critical section, whichever thread enters first obtains exclusive access to the data and upon releasing that access, the other thread is allowed to do whatever it needs to do with the data.

Event handles and critical sections are the most common methods for synchronization in threading environments. As you can see in the above examples, a little bit of planning and forethought will allow you to communicate efficiently between threads and maintain the trust between the threads in your application.

Planning for the Future

It's always good to look toward the future and identify your goals. This article represents the initial steps in building a nice threading model. Tune in next time when I will go into more detail on ways to distribute the work and synchronize to more than one thread to take advantage of today's multi-core processors.

Join the Multi-Threading Revolution

Empower your game with the performance benefits of multi-core by joining the Intel Multi-Core Developer Community. Providing technical information, tools, and support from the industry experts, the Intel Multi-Core Developer Community can help you discover how to best develop parallel programs and multi-threaded applications on multi-core and multi-processor platforms.

Connect with the experts by visiting http://softwarecommunity.intel.com/communities/multicore

Intel does not make any representations or warranties whatsoever regarding quality, reliability, functionality, or compatibility of third-party vendors and their devices. All products, dates, and plans are based on current expectations and subject to change without notice.

Intel, and the Intel logo, are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Other names and brands may be claimed as the property of others.

Further comments for Tommy Refenes about this article may be left at his Intel Software Network blog.


Article Start Previous Page 3 of 3

Related Jobs

innogames
innogames — Hamburg, Germany
[07.10.20]

PHP Game Developer - Grepolis
Remedy Entertainment
Remedy Entertainment — Espoo, Finland
[07.10.20]

Programmer (Character Technology team)
Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan
[07.10.20]

Experienced Game Developer
Klang Games GmbH
Klang Games GmbH — Berlin, Germany
[07.09.20]

AI Engineer (f/m/d)





Loading Comments

loader image