Thu
21
May 2009

Tajemniczy "Ciekawski" prosił, żebym opisał mój asynchroniczy manager zasobów. Zanim go opiszę, muszę napisać słowo o tym, na czym się on opiera - o module do wykonywania zadań w tle.

Ogólnie chodzi o to, aby osobny wątek pracujący w tle wykonał jakieś określone zadanie. Problem w tym, że tworzenie za każdym razem nowego wątku jest powolne. Poza tym przydałoby się, żeby takie zadania były wykonywane po kolei, a nie wszystkie na raz. Dlatego napisałem globalny BkgJobManager, który ma na stałe utworzone wątki, a zadania do wykonania dodaje się do jego kolejki jako obiekty specjalnej klasy BkgJob.

class BkgJobManager {
public:
  BkgJobManager();
  ~BkgJobManager();
  void Init();
  void Frame();
  void AddJob(BkgJob *Job);
  //...
};
extern BkgJobManager *g_BkgJobManager;

Żeby zdefiniować swoje zadanie, trzeba odziedziczyć po klasie BkgJob i zaimplementować metody: OnWork (wywoływaną na osobnym wątku) i opcjonalnie OnWorkDone (wywoływaną po zakończeniu, już na głównym wątku, w ramach wywołania BkgJobManager::Frame).

class BkgJob {
  //...
protected:
  BkgJob(TYPE Type, MODE Mode);
  virtual void OnWork() = 0;
  virtual void OnWorkDone() { }
};

Dodatkowo, klasa pochodna określa typ zadania jako obliczeniowe (mocno angażujące procesor) lub wejścia-wyjścia (wczytujące coś z dysku). To mój oryginalny pomysł oparty na przemyśleniu, że najoptymalniej będzie, jeśli na raz będzie się mogło wykonywać tylko tyle zadań obliczniowych, ile jest rdzeni w procesorze (więcej obniżyłoby wydajność przez częste przełączanie się procesora między wątkami) i tylko jedno zadanie wejścia-wyjścia (więcej obniżyłoby wydajność przez przeskakiwanie głowicy dysku między wieloma czytanymi na raz plikami).

enum TYPE { TYPE_COMPUTATION, TYPE_IO, TYPE_COUNT };

BkgJobManager przechowuje kolejkę zadań do wykonania. Żeby to napisać porządnie, to pewnie powinna być jakaś struktura "lockless", ale ja póki co załatwiłem synchronizację zwykłym muteksem.

Ponadto zadanie ma swój priorytet. Na zadanie można też poczekać, np. wywołując na wątku głównym BkgJob::Join. To wywołanie zwróci sterowanie dopiero, kiedy dane zadanie się zakończy. Jeśli to zadanie czeka gdzieśtam w kolejce, to jego priorytet zostaje podbity, żeby trafiło na przód kolejki.

Ciekawym rozwiązaniem jest, że na wątku głównym należy wołać w każdej klatce (lub inaczej, ale możliwie często) BkgJobManager::Frame. Daje to okazję managerowi, aby "zebrać" wykonane w tle i zakończone zadania, wywołać im BkgJob::OnWorkDone i zwolnić je z pamięci.

Trzeba też pomyśleć, jak z wykonywanej na innym wątku funkcji BkgJob::OnWork przekazywać informację o niepowodzeniu. Ponieważ w swoim kodzie używam wyjątków, łapię wyjątek zgłoszony w BkgJob::OnWork i zachowuję jego obiekt, żeby na wątku głównym móc go potem odczytać.

Podsumowując: Oryginalnie wątek służy do tego, żeby natychmiast rozpocząć wykonywanie jakiejś pracy w tle albo żeby działać cały czas w pętli czekając na jakieś komunikaty. Mechanizm taki jak tutaj przedstawiłem pozwala zmienić koncepcję na taką, w której użytkownik może tworzyć zadania i dodawać je do kolejki, a one będą po kolei wykonywane w tle. Podobny kod - JobSwarm - umieścił na swoim blogu John Ratcliff. Mój można pobrać stąd: BackgroundJob.hpp, BackgroundJob.cpp.

Tego mojego modułu mogę teraz używać do różnych rzeczy, ale podstawowym (i póki co jedynym :) zastosowaniem jest wczytywanie w tle zasobów Direct3D. O samym managerze zasobów napiszę następnym razem...

Comments | #algorithms #c++ #engine Share

Comments