Почему filepath.Walk вешает весь скрипт намертво?

Question

[Михаил]

Здравствуйте, есть проблемный скрипт
Ссылка на плайграунд
в кратце что он должен делать
1. Запускается main
2. Создается отдельная горутина convert которая сидит и слушает канал чтоб взять оттуда обьекты и передать в функицю runconvert если есть обьект то увеличиваем counter на 1, если коунтер меньше 5 если больше ниче не делаем
3. запускаем в бесконечном цикле обход директории и всех поддерикторих которые были указаны при запуске первым аргументом.
4. функция filepath.Walk вызывает на каждый найденый файл walkfunc
5. Walkfunc в свою очередь создает обьект ипихает его в канал где его уже ждут.
6. функция runconvert "отрабатывает" и уменьшает counter на 1 и атк по кругу

все идет по плану 5-6 итераций а потом вешается намертво, при этом, если мы заменим filepath.Walk простым счетчиком допустим от 1 до 1000 создаем обьект и пихаем его в канал то отрабатывает все на ура. как мне это все пофиксить?

UPD: Каунтер нужен для того чтоб runConvert ов было НЕ БОЛЕЕ 5ТИ в одно время, потмоу что если горутинф бцдцт прсото хватить все что попадет в канал они их ранконвертов в скоре наплодят по количечеству файлов, а как написано в исходнике "имитация бурной деятельности" деятельность ествтельно бурная и если пладить беконтрольно то сервак повешается пока не разгребет все а если это 10000000 файлов я потеряю его не неделю нафиг)

Answer 1

[Александр Павлюк]

Вы изменяете глобальную переменную counter из нескольких горутин одновременно, это не потокобезопасно.
Изменение счетчика на +1 или -1 это несколько действий на самом деле.
1. Прочитать значение.
2. Провести с ним операцию инкремента или декремента
3. Записать значение.
А теперь представим, что две горутины одновременно пытаются изменить значение счетчика. Счетчик сейчас равен 5 и горутины пытаются его уменьшить на единицу. Они обе прочитали себе значение 5, уменьшили его на 1, получилось 4, и обе записали 4. При правильной работе мы должны были бы получить 3, так как у нас завершились две runConvert, а получили 4.

Плюс, у вас будет зацикливание на for {} при counter>=5, которое потеснит в планировщике остальные горутины.

Зачем вам вообще этот counter, если есть замечательная вещь — каналы!
pastebin.com/714YTT8U
Нужно просто запустить 5 горутин через go converter() и с помощью каналов между ними будут прекрасно распределяться задачи.

Comments

[Михаил]

пример рабочий но мне нужно ограничение на 5 или любое другое число запущенных оновременно, а у вас они безконтрольно забирают все из канала сколько есть столько и берем!

[Александр Павлюк]

Михаил: у меня как раз это ограничение выставляется константой const NUM_WORKERS = 5
Так как запускаю я только 5 горутин-конвертеров, то они одновременно и забирают только 5 элементов на обработку, а остальные ожидают в очереди, вы запустите и посмотрите лог.

[Александр Павлюк]

Михаил: там еще есть нюанс, про который я не написал. После окончания работы filepath.Walk нужно закрыть канал close(sourceFileChan) и все горутины-обработчики корректно завершатся.

[Михаил]

filepath.Walk не должен останавливатсья никогда, а сканирвоать и сканировать и сканировать) и пихать и пихать и пихать файлы в канал, как разделить новые от уже запиханых это вопрос номер два но сысл именн ов этом)

[Михаил]

видимо я вас не своем понял, и точней я не понял в от эту стрчку

for conv := range sourceFileChan {
println("Имитация бурной деятельности ", conv.Path)
time.Sleep(5 * time.Second)
}
получается горутина забрала файл из канала и завешилась??

[Александр Павлюк]

Михаил: нет, это же основы работы с каналами в go. Если мы применяем range на канал, то мы читаем из канала записи, пока канал не будет закрыт. Т.е., эти 5 горутин, которые запускаются в первом цикле "for i := 0; i < NUM_WORKERS; i++", будут работать все время, вычитывая и обрабатывая записи. А так как этих горутин всего 5, одновременно будет обрабатываться всегда не более 5 записей.

[Михаил]

Александр Павлюк: Да )виноват)) пошел ка я курить go для чайников)) спасибо))

Answer 2

[Алексей]

Скорее всего не Walk вешается, а происходит взаимоблокировка канала.
Например, counter у вас меняется в разных горутинах. В этих случаях, надо использовать блокировки перед изменением с помощью mutex.Lock и Unlock. А так у вас в какой-то момент времени накопился counter> 10,
runConvert не очищает больше канал, а listFunc не может туда ничего писать.
И вообще, зачем counter вводить?
Просто

for {
go runConvert(<-sourceFileChan)
}

должно работать.

Comments

[Михаил]

Каунтер нужен для того чтоб runConvert ов было НЕ БОЛЕЕ 5ТИ в одно время,