Помогите с многопоточным приложением
Здравствуйте.
Нужно создать приложение со множеством потоков. Вот набросал примерную схемку...
Здесь главный поток приложения создает все остальные. Первый отвечает за формирование некой
Нужно создать приложение со множеством потоков. Вот набросал примерную схемку...
Здесь главный поток приложения создает все остальные. Первый отвечает за формирование некой
Если речь о потоках, предположу, что речь идет о работе с общей памятью.
Парадигмой программирования многопоточных приложений на общей памяти являются синхронизация потоков с помощью каких-либо объектов синхронизации. Синхронизация - читай выстраивание нужного порядко выполнения потоков с помощью объектов синхронизации для правильного доступа к элементам общей памяти, т.е. памяти, одновременной используемой несколькими потоками.
В вашем случае видится, например, что
1. Нужен мьютекс на доступ к очереди. Извлечь (или положить) первый элемент из очереди (в очередь) в один момент может только один List-поток или Queue-поток.
2. Аналогично нужны мьютексы на доступ к локальным спискам. У каждой пары должен быть свой мьютекс.
3. Наконец, нужен мьютекс на доступ к главному списку, чтобы разделять этот доступ между List и Main.
Мой приведенный пример использования - очень непроизводительная реализация вашей схемы, она очень "синхронная", на каждой группе стрелочек разрешается работать только одному потоку.
Почитайте про объекты синхронизации, поддерживаемые вашей ОС, выберите подходящие, и поставьте их на стрелочки на вашем рисунке.
Например, то же самое можно реализовать с помощью event'ов и их ожмдания. То есть каждый поток пробуждается только тогда, когда есть условия для его дальнейшей работы, например появился элемент в очереди. Такая "асинхронная" схема будет сложнее по реализации, но производительнее.
Данные никто ни откуда не забирает. Они лежат в общей памяти и ждут своего использования из потоков.
Передайте указатель на соответствующие объекты данных в потоки (queue, list).
Правильная расстановка и использование объектов синхронизации не позволит быть "каше" в queue и list
Парадигмой программирования многопоточных приложений на общей памяти являются синхронизация потоков с помощью каких-либо объектов синхронизации. Синхронизация - читай выстраивание нужного порядко выполнения потоков с помощью объектов синхронизации для правильного доступа к элементам общей памяти, т.е. памяти, одновременной используемой несколькими потоками.
В вашем случае видится, например, что
1. Нужен мьютекс на доступ к очереди. Извлечь (или положить) первый элемент из очереди (в очередь) в один момент может только один List-поток или Queue-поток.
2. Аналогично нужны мьютексы на доступ к локальным спискам. У каждой пары должен быть свой мьютекс.
3. Наконец, нужен мьютекс на доступ к главному списку, чтобы разделять этот доступ между List и Main.
Мой приведенный пример использования - очень непроизводительная реализация вашей схемы, она очень "синхронная", на каждой группе стрелочек разрешается работать только одному потоку.
Почитайте про объекты синхронизации, поддерживаемые вашей ОС, выберите подходящие, и поставьте их на стрелочки на вашем рисунке.
Например, то же самое можно реализовать с помощью event'ов и их ожмдания. То есть каждый поток пробуждается только тогда, когда есть условия для его дальнейшей работы, например появился элемент в очереди. Такая "асинхронная" схема будет сложнее по реализации, но производительнее.
Данные никто ни откуда не забирает. Они лежат в общей памяти и ждут своего использования из потоков.
Передайте указатель на соответствующие объекты данных в потоки (queue, list).
Правильная расстановка и использование объектов синхронизации не позволит быть "каше" в queue и list
очереди, множество потоков разбирают эту очередь, анализируют ее и результаты заносят каждый в свой список. Последний поток забирает инфу со списков, опять таки анализирует ее и передает главному потоку.
Вопрос в том как один поток сможет забрать данные из другого? Заранее спасибо.
Вопрос в том как один поток сможет забрать данные из другого? Заранее спасибо.
Как то не подумал об event'ах... Спасибо.