База для нейросети

[Pavia]

darkwellroad

Как организовать пул из изображений без критической секции?

На мьютексах или спинлоках.
Но вопрос вы задаёте не правильно. Любая синхронизация есть потеря времени.

[Sibedir]

Сообщение от darkwellroad

Блин, ну и срач вы тут развели... Сори за оффтоп. Тему можно наверно закрывать.. Буду писать дальше. И кстати... Как организовать пул из изображений без критической секции?

Попробуй через сообщения
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
http://www.programmersforum.ru/showthread.php?t=109643

Или
а) изначально разбей весь набор на равные N частей (N - кол. потоков).
б) скармливай набор потокам частями (порциями).
Основному потоку (окну) останется дожидаться от каждого потока сообщение об окончании работы, типа
внимание: код вслепую (печатал стазу тут)

SendMessage (Application.MainForm.Handle, WM_USER_THEEND, WPARAM(idThread), 0);

Или

Сообщение от Pavia

На мьютексах или спинлоках.

[Человек_Борща]

Блин, ну и срач вы тут развели... Сори за оффтоп. Тему можно наверно закрывать.. Буду писать дальше. И кстати... Как организовать пул из изображений без критической секции?

Есть такой класс очереди TQueue, вы добавляете туда элементы, а ваши рабочие потоки, в крит. секции делают Extract элемента первого элемента из очереди.
Если хотите без крит. секции, на каждый поток делайте буферную очередь, куда основная очередь будет класть элементы когда сам сможет. Тогда каждый поток будет обращаться к своей буферной очереди без крит. секций. (Опять же надо грамотно это реализовывать).

Sibedir, В какой-то момент времени 2 потока получают сообщение - какое-кому? Там разные картинки, как проверить если это имеет значение?

а) изначально разбей весь набор на равные N частей (N - кол. потоков).
б) скармливай набор потокам частями (порциями).

Неэффективно. Внезапно появилось ещё пара сотен пикчей, им придется ждать завершения всего цикла обработки.

[Sibedir]

Сообщение от Человек_Борща

Если хотите без крит. секции, на каждый поток делайте буферную очередь, куда основная очередь будет класть элементы когда сам сможет.

Я почти это и имел в виду.
Наверное не правильно выразился. Короче, смысл один: каждый поток обрабатывает ограниченную область данных, переданную ему в безграничное пользование, но лишь на время.

Сообщение от Sibedir

а) изначально разбей весь набор на равные N частей (N - кол. потоков).
б) скармливай набор потокам частями (порциями).

Эта самая порция и есть 'буферную очередь'.

-----------------------------------------------------------------

Неэффективно. Внезапно появилось ещё пара сотен пикчей, им придется ждать завершения всего цикла обработки.

Ну да, всё правильно. Если картинки, в какой-то промежуток времени, поступают быстрее, чем они обрабатываются, то им-таки придется ждать своей очереди.
А если картинки всегда поступают быстрее, чем обрабатываются, то это неизбежно приведет к переполнению чего-нибудь (памяти, диска, дескрипторов открытых файлов).

-----------------------------------------------------------------

Sibedir, В какой-то момент времени 2 потока получают сообщение - какое-кому? Там разные картинки, как проверить если это имеет значение?

Не понял.

какое-кому?

Кому отправили, тот и получит.
Или как?

[Человек_Борща]

Кому отправили, тот и получит.
Или как?

Мы говорим о потоках, или вы удумали для каждого потока ещё и окно создавать. Зачем?

Придется в сообщении указывать, какому потоку сообщение.

[Sibedir]

Я предложил, как вариант, для каждого потока создавать очередь сообщений. Та же синхронизация, но очень удобоваримая.

Придется в сообщении указывать, какому потоку сообщение.

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

вы удумали для каждого потока ещё и окно создавать. Зачем?

Как правильно заметил, Pavia (да, думаю, никто и оспаривать не станет).

Сообщение от Pavia

Любая синхронизация есть потеря времени.

[Человек_Борща]

Любая синхронизация есть потеря времени.

Да, но зависит от реализации ПО. Если ПО залочило объект, и не разблокирует его пока не обработает объект - это катастрофа.
Если объект блокируется только на время изъятия элемента для работы - это нормально.

Ну и основная потеря времени это обработка элемента потоком, а в быстроте крит. секций сомневаться можно только в том случае если реализация кривая с использованием этих самых секций.

[Smitt&Wesson]

Сообщение от Человек_Борща

Ну и основная потеря времени это обработка элемента потоком, а в быстроте крит. секций сомневаться можно только в том случае если реализация кривая с использованием этих самых секций.

Человек_Борща, я чё-т не допонял. Ты имеешь в виду, физический сегмент памяти или логический? Понятие - "секция", что это? Впервые услышал в твоём лексиконе. Может я что-то пропустил?

[Человек_Борща]

Человек_Борща, я чё-т не допонял. Ты имеешь в виду, физический сегмент памяти или логический? Понятие - "секция", что это? Впервые услышал в твоём лексиконе. Может я что-то пропустил?

Эмм, критические секции, разрешающие проблемы асинхронного доступа. Давно существуют Или ТС не про эти секции?

[Smitt&Wesson]

Тьфу-ты ну-ты! TCriticalSection Class, это из VCL библиотеки. Проще говоря, это класс привилегированного процесса. Вот, чего я не люблю. Назовут яйцо - ovum или egg. Иди потом и разбирайся, что к чему.