Wątki są powolne, gdy dźwięk jest wyłączony

Question

Mam 2 projekty. Jeden jest budowany przez C++ Builder bez MFC Style. I innym jest VC++ MFC 11.

Kiedy tworzę wątek i tworzę cykl - powiedzmy, że ten cykl dodaje jeden do pozycji w pasku postępu - od 1 do 100 przy użyciu Sleep(10) działa oczywiście zarówno dla C++ Builder, jak i dla C++ Builder. C++ MFC.

Teraz, Sleep(10) to czekać 10 milisekund. OK. Ale problem jest tylko wtedy, gdy mam otwarty odtwarzacz multimedialny, Winamp lub cokolwiek innego, co produkuje "Dźwięk". Jeśli zamknę wszystkie odtwarzacze multimedialne, winampy i inne programy dźwiękowe, moje wątki będą wolniejsze niż 10 milisekund.

Trwa jak 50-100 ms/each. Jeśli otworzę dowolną muzykę, działa ona normalnie tak, jak się spodziewałem.

Nie mam pojęcia, dlaczego tak się dzieje. Najpierw pomyślałem, że popełniłem błąd w aplikacji MFC, ale dlaczego C++ Builder również zwalnia?

I tak, jestem pewny, że jest to związane z dźwiękiem, ponieważ nawet zmieniłem kształt okien, wyłączyłem wszystko. W końcu odkryłem ten problem z dźwiękiem.

Czy mój kod coś potrzebuje?

Aktualizacja:

Teraz śledzę kod i okazało się, że stosowane w takich dziedzinach Sleep(1) czekać 1 milisekundy. Powodem tego jest przesunięcie obiektu z lewej na prawą. Jeśli usunę ten sen, ruch nie pojawi się, ponieważ jest bardzo szybki. Więc powinienem użyć Sleep(1). Z Sleep(1), jeśli dźwięk jest na niż działa. Jeśli dźwięk jest wyłączony niż jest bardzo wolny.

for (int i = 0; i <= 500; i++) { 
    theDialog->staticText->SetWindowsPosition(NULL, i, 20, 0, 0); 
    Sleep(1); 
} 

Propozycje w tym zakresie są naprawdę mile widziane. Co powinienem zrobić?

Wiem, że to niewłaściwy sposób. Powinienem użyć czegoś, co jest właściwe i ważne. Ale co dokładnie? Która funkcja lub klasa pomaga mi płynnie przenosić tekst statyczny z jednej pozycji na drugą?

Również zmiana priorytetu wątku nie pomogła.

Aktualizacja 2:

Update 1 jest inna kwestia :)

Answer 1

Uśpienie (10), będzie (jak wiadomo) czekać około 10 milisekund. Jeśli istnieje wątek o wyższym priorytecie, który musi zostać uruchomiony w tym momencie, wątek może być opóźniony. Nici multimedialne prawdopodobnie działają w czasie rzeczywistym lub wysokim priorytecie, więc podczas odtwarzania dźwięku wątek zostanie opóźniony.

Patrz Jeffrey Richters komentarzu w programowaniu aplikacji dla Microsoft Windows (4th ed), sekcja spanie w rozdziale 7:

System sprawia, że ​​nić nie szeregowaniu zadań przez około liczbie milisekund określonych. Zgadza się - jeśli powiesz systemowi, że chcesz spać przez 100 milisekund, będziesz spać około przez tak długi, ale być może kilka sekund lub minut dłużej. Pamiętaj, że system Windows nie jest systemem operacyjnym czasu rzeczywistego. Twój wątek będzie prawdopodobnie obudzić we właściwym czasie, ale czy to zależy od tego, co jeszcze jest dzieje się w systemie.

Również zgodnie MSDN Multimedia Class Scheduler Service (Windows)

MMCSS zapewnia, że ​​czas przetwarzania wrażliwych otrzymuje priorytet dostępu do zasobów procesora.

Według powyższej dokumentacji, można również kontrolować procent zasobów procesora, które będą gwarantowane do zadań o niskim priorytecie, za pomocą klucza rejestru szeroki

Answer 2

Sleep(10) czeka przynajmniej 10 milisekund. Musisz napisać kod, aby sprawdzić, ile czasu faktycznie czekałeś i czy jest to więcej niż 10 milisekund, obsłużyć to w swoim kodzie. Windows nie jest systemem operacyjnym działającym w czasie rzeczywistym.

Answer 3

Minimalna rozdzielczość Sleep() czasu jest ustawiony system z timeBeginPeriod() i timeEndPeriod(). Na przykład podanie timeBeginPeriod(1) ustawia minimalną rozdzielczość na 1 ms. Możliwe, że programy audio ustawiają rozdzielczość na 1 ms i przywracają ją do wartości większej niż 10 ms po zakończeniu. Miałem problem z programem, który używał Sleep(1), który działał poprawnie tylko wtedy, gdy XE2 IDE działał, ale inaczej spałby przez 12 ms. Rozwiązałem problem bezpośrednio ustawiając timeBeginPeriod(1) na początku mojego programu.

Zobacz: http://msdn.microsoft.com/en-us/library/windows/desktop/dd757624%28v=vs.85%29.aspx