作者：龍飛
2.1：競(jìng)爭(zhēng)條件（Race Conditions）
我們?cè)谇懊鎸⒁粋€(gè)普通函數(shù)調(diào)用轉(zhuǎn)換成了用線程調(diào)用，這意味著我們可以“同時(shí)”調(diào)用兩個(gè)以上的線程。例如，我們希望在屏幕的另外一個(gè)位置也播放這段簡(jiǎn)單的動(dòng)畫(huà)，我們只需要添加一個(gè)線程的調(diào)用就可以了。
int main(int argc ,char* argv[])
{
//Create a SDL screen.
const int SCREEN_WIDTH = 640;
const int SCREEN_HEIGHT = 480;
const Uint32 SCREEN_FLAGS = 0; //SDL_FULLSCREEN | SDL_DOUBLEBUF | SDL_HWSURFACE
const std::string WINDOW_NAME = "Amn Test";
ScreenSurface screen(SCREEN_WIDTH, SCREEN_HEIGHT, WINDOW_NAME, 0, SCREEN_FLAGS);
PictureSurface bg("./images/background.png", screen);
bg.blit(0);
screen.flip();
AmnArg test1(0, 250, 600, 250, screen);
SDL_Thread* thread1 = SDL_CreateThread(amn, (void*)&test1);
AmnArg test2(0, 0, 600, 0, screen);
SDL_Thread* thread2 = SDL_CreateThread(amn, (void*)&test2);
SDL_Event gameEvent;
bool gameOver = false;
while ( gameOver == false ){
while ( SDL_PollEvent(&gameEvent) != 0 ){
if ( gameEvent.type == SDL_QUIT ){
gameOver = true;
}
if ( gameEvent.type == SDL_KEYDOWN ){
if ( gameEvent.key.keysym.sym == SDLK_ESCAPE ){
gameOver = true;
}
}
screen.flip();
}
}
SDL_KillThread(thread1);
SDL_KillThread(thread2);
return 0;
}
這段程序看起來(lái)似乎沒(méi)有什么問(wèn)題，但是運(yùn)行的時(shí)候，不可預(yù)知的情況出現(xiàn)了：理論上我們幾乎同時(shí)調(diào)用了兩個(gè)線程，動(dòng)畫(huà)似乎應(yīng)該是同步播放的，但是實(shí)際上，兩段動(dòng)畫(huà)的播放并不同步，并且每次執(zhí)行的效果都不一樣——有時(shí)候上面的圖片移動(dòng)快，有時(shí)候下面的圖片移動(dòng)快，并且速度不均勻。
這就是典型的race conditions的表現(xiàn)。還記得我說(shuō)過(guò)沒(méi)有定義dt嗎，我們讓電腦以其所能達(dá)到的最快速度決定dt，換句話說(shuō)，我們每一個(gè)線程都試圖“咬死”CPU的運(yùn)算，當(dāng)然，在實(shí)際中多任務(wù)的OS會(huì)幫助CPU分配任務(wù)，但是如何分配卻是不確定的，因?yàn)镺S并不知道哪些任務(wù)需要優(yōu)先執(zhí)行，所以，兩個(gè)線程實(shí)際上在競(jìng)爭(zhēng)電腦的性能資源，產(chǎn)生的結(jié)果就是不確定的。
2.2：松開(kāi)“死咬”的CPU
void SDL_Delay(Uint32 ms);
解決race conditions的方法就是給CPU足夠的時(shí)間“休息”，而這正好也是我們自己定義dt所需要的。SDL_Delay()在這個(gè)時(shí)候就顯得意義重大了。當(dāng)今電腦的運(yùn)算速度非常非常快，以至于哪怕我們僅僅給電腦0.01秒的時(shí)間“休息”（每次循環(huán)中），電腦都會(huì)顯得很輕松了。
int amn(void* data)
{
AmnArg* pData = (AmnArg*)data;
PictureSurface stand("./images/am01.png", pData->screen);
stand.colorKey();
PictureSurface bg("./images/background.png", pData->screen);
const int SPEED_CTRL = 300;
int speedX = (pData->endX - pData->beginX) / SPEED_CTRL;
int speedY = (pData->endY - pData->beginY) / SPEED_CTRL;
for ( int i = 0; i < SPEED_CTRL; i++ ){
pData->beginX += speedX;
pData->beginY += speedY;
bg.blit(pData->beginX, pData->beginY, pData->beginX, pData->beginY, stand.point()->w, stand.point()->h, 2, 2);
stand.blit(pData->beginX, pData->beginY);
pData->screen.flip();
SDL_Delay(10);
}
return 0;
}
說(shuō)到這里，我們不得不提及之前一直所忽略的一個(gè)問(wèn)題：我們之前凡是涉及循環(huán)等待事件輪詢的程序總是占用100%的CPU，這并不是因?yàn)槲覀冋嬲玫搅?00%的CPU性能，而是我們讓CPU陷入了“空等”（Busy Waiting）的尷尬境地。輪詢事件得到響應(yīng)相對(duì)于循環(huán)等待來(lái)說(shuō)，是發(fā)生得非常緩慢的事情，我們?cè)谘h(huán)中，哪怕是讓電腦休息0.01秒，事情都會(huì)發(fā)生本質(zhì)性的改變：
while ( gameOver == false ){
while ( SDL_PollEvent(&gameEvent) != 0 ){
if ( gameEvent.type == SDL_QUIT ){
gameOver = true;
}
if ( gameEvent.type == SDL_KEYDOWN ){
if ( gameEvent.key.keysym.sym == SDLK_ESCAPE ){
gameOver = true;
}
}
screen.flip();
}
SDL_Delay(10);
}
當(dāng)我們重新運(yùn)行新程序的時(shí)候，我們可以看到程序?qū)PU的占用從100%驟降到了0%！這當(dāng)然并不意味著程序就用不上CPU了，而是說(shuō)，這些運(yùn)算對(duì)于我們的CPU來(lái)說(shuō)，實(shí)在是小菜一碟了，或者從數(shù)據(jù)上說(shuō)，處理這些運(yùn)算的時(shí)間與0.01秒來(lái)比較，都幾乎可以忽略不計(jì)！
2.3：GUI線程與worker線程
我們的另外一項(xiàng)試驗(yàn)是將事件輪詢放到動(dòng)畫(huà)線程中，程序就不多寫(xiě)了，大家可以自己試下。我直接說(shuō)結(jié)論：動(dòng)畫(huà)線程中無(wú)法響應(yīng)事件輪詢。
一般提倡的模式，是將GUI事件都寫(xiě)在主線程中，而將純粹的運(yùn)算才寫(xiě)到由主線程創(chuàng)建的線程中，后者也就是所謂的worker線程。從另外一個(gè)概念看，只有主線程控制著“當(dāng)前窗口”，其它線程也許在后臺(tái)，也許雖然也是在前臺(tái)但是并非是我們可見(jiàn)的，所以，輪詢事件找不到接口。
對(duì)于拋出的線程與主線程之間的通訊，我們可以通過(guò)他們共享的數(shù)據(jù)來(lái)進(jìn)行控制，所以，盡管事件輪詢不能直接影響worker線程，但是我們?nèi)匀皇强梢酝ㄟ^(guò)主線程進(jìn)行間接影響的。
posted on 2008-04-28 12:47
lf426 閱讀(6793)
評(píng)論(0) 編輯 收藏 引用 所屬分類(lèi):
SDL入門(mén)教程