ReSQL.ru
     
powered by simpleCommunicator - 2.0.56     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Нужен совет по реализации многопоточного приложения
25 сообщений из 52, страница 1 из 3
  1  все
Нужен совет по реализации многопоточного приложения
    #38639552
darlov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
darlov
Гость
Доброго времени суток, не хватает познаний в реализации.
Имеется программа которая многопоточно опрашивает серверы, необходимо эти данные складывать в массив или в коллекцию для дальнейшей вставки в БД. Как лучше реализовать вставку всех данных с разных потоков в один массив и потом из массива в БД, ведь пока будет идти запрос вставки в БД, массив будет заполнятся.
Заранее благодарен.
...
Рейтинг: 0 / 0
13.05.2014, 11:39
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38639605
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arm79
Участник
ConcurrentQueue
...
Рейтинг: 0 / 0
13.05.2014, 12:15
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38639903
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
Может проще вставлять из "много потоков" сразу в БД?
...
Рейтинг: 0 / 0
13.05.2014, 15:32
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38640468
darlov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
darlov
Гость
За ConcurrentQueue спасибо, не знал....
Алексей КМожет проще вставлять из "много потоков" сразу в БД?
В таком случае буду тормозить потоки с данными или есть иной способ?
Работаю с PostgreSQL
...
Рейтинг: 0 / 0
14.05.2014, 05:56
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38640556
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
darlov,
основная очередь - А
у каждого потока своя небольшая очередь - Б
потоки получая данные пишут сперва свою очередь (Б), как только в этой очереди, больше n записей (например 50) -
поток пробует захватить локер очереди А, и быстренько сливает туда n записей.

другой поток, к примеру раз в 5 секунд, заглядывает в очередь А, лочит её, и быстренько копирует в свою очередь С, и а "отпускает", после чего, не спеша, из очереди С все пишет в базу данных.
...
Рейтинг: 0 / 0
14.05.2014, 09:36
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38640564
darlov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
darlov
Гость
Кифирчикdarlov,
основная очередь - А
у каждого потока своя небольшая очередь - Б
потоки получая данные пишут сперва свою очередь (Б), как только в этой очереди, больше n записей (например 50) -
поток пробует захватить локер очереди А, и быстренько сливает туда n записей.

другой поток, к примеру раз в 5 секунд, заглядывает в очередь А, лочит её, и быстренько копирует в свою очередь С, и а "отпускает", после чего, не спеша, из очереди С все пишет в базу данных.
А чем плох ConcurrentQueue?
Каждый поток заполняет общий ConcurrentQueue методом Enqueue, а отдельный поток забирает оттуда методом TryDequeue (удаляя старые записи) и вставляет в БД оператором COPY
...
Рейтинг: 0 / 0
14.05.2014, 09:45
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38640576
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
darlovВ таком случае буду тормозить потоки с даннымиВ противном случае очередь будет наполняться быстрее чем освобождаться, что приведёт к OutOfMemory ?
...
Рейтинг: 0 / 0
14.05.2014, 09:57
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38640603
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
darlov...А чем плох ConcurrentQueue?...
я не говорю что он плох, лично руками ConcurrentQueue "не трогал", и её комментировать не могу )
...
Рейтинг: 0 / 0
14.05.2014, 10:16
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38640627
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Где-то в степи
Участник
darlov В таком случае буду тормозить потоки с данными
Рассматривайте поток как единицу работы.
Алексей К В противном случае очередь будет наполняться быстрее чем освобождаться, что приведёт к OutOfMemory ?
Имхо, слоны раньше сдохнут - чем куча иссякнет..
...
Рейтинг: 0 / 0
14.05.2014, 10:28
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38640638
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЕвгенийВ
Участник
darlov,
используемый провайдер поддерживаем для XXXCommand методы Begin/EndExecuteNonQuery?
...
Рейтинг: 0 / 0
14.05.2014, 11:03
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38640719
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
Где-то в степиАлексей К В противном случае очередь будет наполняться быстрее чем освобождаться, что приведёт к OutOfMemory ?
Имхо, слоны раньше сдохнут - чем куча иссякнет..Кто знает. Продолжительность жизни слонов - 70-100 лет.
...
Рейтинг: 0 / 0
14.05.2014, 11:43
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38640805
darlov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
darlov
Гость
Спасибо за ответы... Думаю надо тестировать в двух вариантах, не знаю как себя поведет проект при многопоточной вставке в БД большого объема данных...
...
Рейтинг: 0 / 0
14.05.2014, 12:33
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38640812
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЕвгенийВ
Участник
Алексей ККто знает. Продолжительность жизни слонов - 70-100 лет.
И они умирают от голода, когда стираются последние третьи зубы.
...
Рейтинг: 0 / 0
14.05.2014, 12:38
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38641161
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Где-то в степи
Участник
Алексей КГде-то в степипропущено...

Имхо, слоны раньше сдохнут - чем куча иссякнет..Кто знает. Продолжительность жизни слонов - 70-100 лет.
так если рассуждать гипотетически, то уходя из дома на работу нужно прощаться с родными навсегда ( каждый раз)..
хз, может и машина переехать, или скушать не того..., а приходя домой говорить - охя удача, я вернулся живым..
...
Рейтинг: 0 / 0
14.05.2014, 15:34
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38641172
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arm79
Участник
Кифирчикdarlov...А чем плох ConcurrentQueue?...
я не говорю что он плох, лично руками ConcurrentQueue "не трогал", и её комментировать не могу )
Я пробовал. Ничем не плох. Наоборот, всем хорош :-). И лочить ничего не нужно.

Если потоки генерируют данные быстрее, чем в состоянии переварить СУБД, то хоть как распределяй, накопление в очереди будет.

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

darlovкак себя поведет проект при многопоточной вставке в БД большого объема данных
Зависит от СУБД. К тому же не озвучены критерии "большого" объема данных. Это сколько и как часто?

Где-то в степито уходя из дома на работу нужно прощаться с родными навсегда ( каждый раз)..
На самом деле это очень хороший совет.
...
Рейтинг: 0 / 0
14.05.2014, 15:40
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38641182
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
Где-то в степиАлексей Кпропущено...
Кто знает. Продолжительность жизни слонов - 70-100 лет.
так если рассуждать гипотетически, то уходя из дома на работу нужно прощаться с родными навсегда ( каждый раз)..
хз, может и машина переехать, или скушать не того..., а приходя домой говорить - охя удача, я вернулся живым..
YouTube Video
YouTube Video
...
Рейтинг: 0 / 0
14.05.2014, 15:47
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38641191
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
Arm79Вариант, когда каждый поток сам пишет в БД рабочий, но лично мне не нравится размазывание функциональности.Отнюдь. Всё зависит от написания программы. Ничто не мешает разделить запись в БД и опрос датчиков по разным классам. Один поток необязательно должен соответствовать одному классу.
...
Рейтинг: 0 / 0
14.05.2014, 15:54
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38641199
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arm79
Участник
Алексей КНичто не мешает разделить запись в БД и опрос датчиков по разным классам
Ничто не мешает. Но это может мне не нравиться?
...
Рейтинг: 0 / 0
14.05.2014, 15:57
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38641209
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
Arm79Алексей КНичто не мешает разделить запись в БД и опрос датчиков по разным классам
Ничто не мешает. Но это может мне не нравиться?Конечно.
...
Рейтинг: 0 / 0
14.05.2014, 16:05
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38641211
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Где-то в степи
Участник
Алексей К,
можно, но не приветствую, имхо вставка должна осуществляться с одного места через буфер тем более если
есть несколько претендентов на вставку в очереди, можно объединить их все в одну команду, и будет ли это быстрее
чем вставка в каждой единице работы не известно, ибо есть такое ограничение ( из рихтера)
из потоков обращение к куче может делать только один поток, остальные ждут, пока куча освободится, а пока ждут
это и регистры сбрасываются, и кеш первого уровня очищается....
...
Рейтинг: 0 / 0
14.05.2014, 16:07
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38641235
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
Где-то в степиАлексей К,
можно, но не приветствуюИ не надо. Достаточно огласить весь список, с преимуществами и недостатками возможных подходов. ТС пусть сам решает что ему больше подходит.
Где-то в степи, имхо вставка должна осуществляться с одного места через буфер тем более если
есть несколько претендентов на вставку в очереди, можно объединить их все в одну командуВ каждом потоке так же можно организовать объединение нескольких вставок в пакет (SQL batch).
Где-то в степи, и будет ли это быстрее
чем вставка в каждой единице работы не известноЕсли есть возможность объединить в пакеты (SQL batch), то вставка будет намного быстрее.
Где-то в степи, ибо есть такое ограничение (из рихтера)
из потоков обращение к куче может делать только один поток, остальные ждут, пока куча освободится, а пока ждут
это и регистры сбрасываются, и кеш первого уровня очищается....Экономия на спичках.
...
Рейтинг: 0 / 0
14.05.2014, 16:20
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38641242
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Где-то в степи
Участник
Алексей К,
авторЭкономия на спичках.
Имхо нет, писать эффективные потоки верх совершенства.
...
Рейтинг: 0 / 0
14.05.2014, 16:24
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38641272
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
Где-то в степиАлексей К,
авторЭкономия на спичках.
Имхо нет, писать эффективные потоки верх совершенства.Необходимость межпроцессного взаимодействия, в данном случае необходимость опроса серверов и записи в БД, сводит все эти оптимизации к нулю.
...
Рейтинг: 0 / 0
14.05.2014, 16:39
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38641432
bazile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bazile
Участник
Где-то в степиибо есть такое ограничение ( из рихтера)
из потоков обращение к куче может делать только один поток, остальные ждут, пока куча освободится
Ты что-то путаешь. Если бы потоки ждали бы своей очереди для доступа к куче, то не было бы никакой необходимости в lock и в других методах синхронизации.
...
Рейтинг: 0 / 0
14.05.2014, 18:35
| Ответить | Цитировать | Написать  
Нужен совет по реализации многопоточного приложения
    #38641483
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Где-то в степи
Участник
bazile, причем тут lock и синхронизация потоков?
куча такой же разделяемый ресурс между потоками, как и то о чем вы думаете.
только синхронизация доступом к куче управляется ядром системы, если один поток создает в куче что то new а
другой пытается создать то же что то или изменить размер уже созданного что то, то система ставит эти потоки в очередь для обращения ( один изменяет, другой ждет)
...
Рейтинг: 0 / 0
14.05.2014, 19:44
| Ответить | Цитировать | Написать  
25 сообщений из 52, страница 1 из 3
  1  все
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Нужен совет по реализации многопоточного приложения
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=20&msg=38640638&tid=1402922]:
 0ms
get settings:
 8ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 38ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 57ms
get tp. blocked users:
 2ms
others: 11ms
total:  148ms
созд. / загр.: 148ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]