2015-02-01 2 views
2

У меня есть два потока. Оба разговаривают с GPU. Первый отвечает за рендеринг другого для загрузки материала. Когда первый на самом деле делает рендеринг и не делает других вещей, второй должен остановиться. Они могут работать параллельно, но это приведет к появлению всплесков частоты кадров. Так что нормально делать одну петлю при загрузке потока, но не более того. Я реализовал это поведение с помощью std :: mutex, но мне это не нравится, поскольку второй поток фактически переключает мьютекс и может замедлить поток рендеринга. Как это можно реализовать чище?Как определить std :: mutex?

//Master thread 
{ 
    std::lock_guard<std::mutex> lg(gpuMutex); 
    // rendering 
} 

//Slave thread 
while(!toLoadQueue.isEmpty()) { 
    gpuMutex.lock(); 
    gpuMutex.unlock(); 
    // loading 
} 

Edit: Comparison Сравнение шахты (синий) и @ (красный) код Бэрри. (менее шип лучше)

Visualization Визуализация того, как должны вести себя потоки.

ответ

3

Я хотел бы использовать condition_variable и atomic<bool>:

// in master 
available = false; 
std::lock_guard<std::mutex> lock(gpuMutex); 
// [ do stuff ... ] 
// ok ready to let go 
available = true; 
cv.notify_one(); 

Ведомый только wait s на condition_variable быть notify ред. Мы добавляем в atomic<bool>, чтобы избежать побочного пробуждения.

// in slave 
std::unique_lock<std::mutex> lock(gpuMutex); 
cv.wait(lock, [&]{ return available.load(); }); 
+0

Ну, я действительно смущен. Вы знаете, почему ваше решение работает намного лучше? – Keo

+2

Это неэффективно, поскольку 'доступно' является атомарным. Это может быть простой «bool», поскольку он всегда читается и записывается с закрытым «gpuMutex». В противном случае я согласен, что это путь. –

+0

@ Keo Я не могу сформулировать разум, достаточный для того, чтобы я опубликовал его как ответ, если бы это был вопрос. Я полагаю, что 'condition_variable' предназначен для решения этой проблемы - так оно и есть? – Barry

Смежные вопросы