Я создаю потоки boost внутри функции с помощью
while(trueNonceQueue.empty() && block.nNonce < std::numeric_limits<uint64_t>::max()){
if ( block.nNonce % 100000 == 0 )
{
cout << block.nNonce << endl;
}
boost::thread t(CheckNonce, block);
t.detach();
block.nNonce++;
}
uint64 trueNonce;
while (trueNonceQueue.pop(trueNonce))
block.nNonce = trueNonce;
trueNonceQueue
был создан с boost::lockfree::queue<uint64> trueNonceQueue(128);
в глобальном масштабе.
Это функция, которая имеет резьбу
void CheckNonce(CBlock block){
if(block.CheckBlockSilently()){
while (!trueNonceQueue.push(block.nNonce))
;
}
}
Я заметил, что после того, как он разбился, мой своп вырос незначительно, что никогда не произойдет, если я не использую такую технику после утечки памяти; в противном случае, использование моей памяти часто бывает ниже 2 концертов. Я запускаю корицу на рабочем столе ubuntu с хром и несколько других небольших программ. Я не использовал компьютер в то время, когда он работал.
Сегфакт произошел после 949900000
й итерации. Как это можно исправить?
CheckNonce
выполнения CheckNonce
Я добавил тот же модуль к CheckNonce
чтобы узнать, есть ли какое-либо отставание. Пока их нет.
Я буду обновлять, если отдельные потоки начинают отставать от нерестового while
.
Вместо этого вы должны использовать пул потоков. Это означает, что для создания работы без чрезмерного разногласия (например, для N-2 потоков на N-ядерной машине, но, возможно, больше, если какая-то работа может блокировать операции ввода-вывода) может возникнуть только поток потоков.
В Boost нет ни одного пула потоков, но есть части, которые вам нужно собрать. См. Здесь некоторые идеи: boost :: threadpool :: pool vs.boost :: thread_group
Или вы можете использовать более готовое решение, подобное этому (хотя оно немного устарело и, возможно, не поддерживается, не уверен): http://threadpool.sourceforge.net/
Тогда идея состоит в том, чтобы создать N потоков, а затем в вашем цикле для каждой задачи просто "отправить" задачу в пул потоков, где следующий доступный рабочий поток подберет ее.
Делая это, вы избежите многих проблем, таких как нехватка пространства стека в потоках, избегая неэффективных конфликтов ресурсов (посмотрите на проблему "громоподобного стада"), и вы сможете легко настроить агрессивность, с которой вы используете несколько ядер на любой системе.
thread_group
, использую все свои ядра, и он хэширует в 10 раз больше, чем было, и я даже могу продолжать использовать мой компьютер! Я был раньше, но мой системный монитор показывает 100% использования на всех ядрах.