Здравствуйте. Есть 2 потока c бесконечным циклом. Один генерирует файлы

и наполняет ими контейнер. Другой забирает эти файлы на отправку и очищает контейнер. У каждого своя периодичность цикла, которую можно задать по времени. Правильно ли будет использовать volatile для контейнера? Нет ли риска потерять данные при этом?

а что за контейнер? Звучит как задача для BlockingQueue или подобных решений которые уже есть готовые

мапа <String, List<File>>. При блокировке получается ситуация, что если первый поток выполняет много работы, то он так и не отдает управление контейнером второму потоку. Забираю данные, создавая новую мапу: val data = HashMap(container) container.clear()

Надо через одну структуру вести обмен и делать это быстро. Быстро положить готовые данные и быстро забрать, чтобы никого не блокировать. Задача producer-consumer.

Так есть же concurent мапы всякие готовые, посмотри и выбери что подходит. А то звучит как-то странно, что ты делаешь

типичный consumer producer. В с++ решалось через condition_variable. (И без "У каждого своя периодичность цикла", но может вам это зачем-то нужно.) Посмотрите в сторону concurrent queue и оцените, можете ли отказаться от "периодичности цикла".

+1. Быстро скопировать File из мапы, удалить из мапы и отдать lock

Спасибо, изучу. От периодичность отказаться не могу по тз, к сожалению

Кооперативную многопоточность знаете? При таком тз выглядит, как кейз для нее

не знакома, пошла гуглить)

> У каждого _своя_ или не для кооп. мн., если у одного цикл 2 сек из 4х, а у второго 4 из 6 (а не так, что сначала 2 сек из 5 один, а потом оставшиеся 3 из 5 второй). Вообще такое тз странное, ну да ладно. Это лаба/домашка или что-то коммерческое?

рабочая задача

Успезов

Ну и пусть producer и consumer с нужной им периодичностью используют общую синхронизированную структуру для обмена данными. Нужно только учесть, что как минимум запись в очередь будет блокировать читателя.

вот с этим я и столкнулась, что при маленьком периоде и большом объеме записи, управление до читателя просто не доходит 😞

подозреваю, что у вас продюсер делает проверить таймер, взять лок, создать данные, положить в контейнер, отдать лок а надо примерно так проверить таймер, создать данные, взять лок, положить в контейнер, отдать лок в консюмере действовать аналогично Кстати, не оч понятно,, зачем была взята мапа. Смотрите в сторону concurrent queue

Потому что общие данные нужно менять быстро и сразу отпускать 😏 Interthread communication - оно такое.

При совсем маленьком периоде, если без аналога condition_variable, вы можете получить live lock (а не deadlock), что вы м.б. и получаете

по второму сценарию делаю) первый поток опрашивает поставщиков данных, которые отдают ему уже готовые списки файлов и сохраняет в мапу <Поставщик, список файлов>

к черту карту, вставайте в очередь. вам уже несколько чел написали

спасибо, видимо тогда придется делать объекты для очереди, т.к. у каждого файла должна сохраняться инфа о поставщике

но все равно, если у вас в бассейн (контейнер) через трубу стабильно вливается больше, чем может вылиться из слива, то бассейн в конце концов переполнится. нужно, чтобы in the long run производительность консьюмеров была не меньше, чем продьюсеров