2011-06-13 59 views
3

我目前正在開發一個XNA項目,它將從本地SQL數據庫中提取有關每個對象(每個對象都將顯示在屏幕上)的信息(ID,名稱,文件位置等)。如何使用線程在XNA中運行數據庫查詢?

我想在單獨的線程上運行我的數據庫查詢,以便在數據庫掛起或發生其他不可預見的事件時,呈現的屏幕不會凍結。我使用的是XNA 4.0,該應用程序只能在Windows上運行。 這是可能的,如果是這樣,怎麼樣?

+1

難道你只是在遊戲開始時緩存這些信息嗎? – Will 2011-06-13 15:40:49

+0

是的,一些信息在啓動時被緩存。還有其他信息由數據庫更新,我必須在程序運行時對其進行計算,新的值必須顯示在屏幕上。 – NexAddo 2011-06-13 16:26:03

回答

2

有很多選項可用。一般而言,您需要查詢在單獨的線程中運行。您可以使用

  1. 線程池

  2. 手動創建的線程herehere

我將開始與線程池,看看它是如何工作的,專用的手動線程不是在內存管理和再利用方面是穩健的。

+0

我想我將研究使用數據庫的異步調用。一旦我取得了一些進展,我會迴應它的方式。謝謝! – NexAddo 2011-06-13 16:09:26

+0

事實證明,我們沒有必要讓我們的數據庫調用畢竟是異步的。感謝所有的幫助。 – NexAddo 2011-06-15 16:09:40

0

根本沒有這樣做。認真。有充分的理由使用線程的,但你的理由是假的:

如果數據庫掛起或其他一些不可預見的事件發生

數據庫不掛和不可預見的事件所呈現的畫面也不會凍結未預見的事件。例如,如何處理數據庫不能應答3分鐘?顯示未知對象的屏幕?

+1

我認爲問題的精神是如何在程序嘗試從數據庫獲取數據時保持屏幕響應,即使數據庫正確執行,對於大型或複雜查詢或通過慢速網絡連接,也可能需要幾秒鐘的時間。從這個意義上說,是的,數據庫將「掛起」,並且當程序等待時,如果UI線程在通話中被阻塞,它將不會呈現。 – KeithS 2011-06-13 15:53:48

+0

問題在於,在給出的例子中它沒有任何意義 - 例如,當東西加載在背景中時,您不能在有趣的遊戲世界中玩遊戲。 – TomTom 2011-06-13 16:02:58

+0

我將來會更加清楚。一種情況可能是在從數據庫加載所有初始遊戲對象之後,當前屏幕上的某個對象的某些信息將從應用程序外部更新。如果出於某種原因,我不希望用戶界面掛起,如果它出現這種情況需要更長的時間。然後,在更新信息之後,它將在屏幕上顯示新信息。 – NexAddo 2011-06-13 16:22:23

0

你是什麼意思「最好的」?有很多方法可以使用線程,它們都有優點和缺點。

聲明一個新的線程明確並啓動它可以讓你在該線程的執行狀態的最直接的控制:

var myDbThread = new Thread(()=>myDbRepo.GetRecordById<MyEntity>(idString)); 
myDbThread.Start(); 

現在,只要你有myDbThread一個參考,你可以放棄它,暫停它,加入它等等,但是,控制來自責任;你必須管理你自己創建的線程。

對於大多數並行任務,建議使用ThreadPool。但是,你失去了一些控制的:

Action myDbLambda =() => myEntityProperty = myDbRepo.GetRecordById<MyEntity>(idString); 
var asyncResult = myDbLambda.BeginInvoke(); 

一旦asyncResult.IsComplete返回true,myEntityProperty具有價值。您也可以將其設計爲Func,並使用回調來設置值(建議使用此值)。異步模型內置於BeginInvoke()/ EndInvoke()方法對中,並且ThreadPool預計會有很多異常,例如超時,這將簡單地重新啓動超時線程。然而,你不能「放棄」並終止一個ThreadPool線程,在ThreadPool線程上「加入」會有點棘手,如果你啓動了很多線程,ThreadPool將以250ms爲間隔啓動它們,充分利用處理器。

有很多方法可以使用ThreadPool;在代碼在v3.5中對.NET編程變得更加重要之前,ThreadPool.QueueUserWorkItem是主要方法。現在,正如我所說的,代表們擁有BeginInvoke和EndInvoke方法,允許您使用後臺內置的異步模型啓動後臺進程。在WinForms/WPF中,您還可以創建事件驅動的BackgroundWorker組件,允許您監視GUI元素中的進度和完成情況。

有一點要注意;在ASP.NET中使用後臺線程幾乎不是一個好主意。除非你真的知道你在做什麼,否則最好的情況是你不會得到你發送給工作線程的行爲的結果,最糟糕的情況是你可能會讓你的網站崩潰。

相關問題