Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
ДохтаР, Читателю неизвестно о существовании объекта до тех пор, пока он не находится в консистентном состоянии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 10:46 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
WesttrdДохтаР, Читателю неизвестно о существовании объекта до тех пор, пока он не находится в консистентном состоянии. Вы исключаете возможность изменения состояния в процессе работы читателя над обьектом ? Как писатели узнает о том, что обьект сейчас обрабатывается читателем ? У вас синхронный конвеер ? ( в один момент времени с обьектом работает одна нить исполнения и по конвееру передает обьект дальше) Мы ведь вроде как об аснхронной многопоточной обработке говорим . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 11:14 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
ДохтаР, Я писал про исключительно имплементации очередей FIFO. После попадания в очередь объект, как правило, не изменяется. В случае, если изменение возможно, применяются иные архитектурные решения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 11:45 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
WesttrdДохтаР, Я писал про исключительно имплементации очередей FIFO. Поэтому я задал наводящие вопросы про конвеер, для однозначности понимания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 11:55 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
Westtrdсамый производительный способ, Это решение описано в специализированных проектах - курсор читателя если они не связаны логически, ДОЛЖЕН быть независимым, и оверхеда тут практически никакого А как писатель узнает, что читатель уже прочитал данную запись? И как читатели узнают какие записи им читать, чтобы не было чтений одной записи разными читателями, или они идут с шагом i = n * count_of_readers? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 12:33 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
читатель уже прочиталИ как читатели узнают какие записи им читать, чтобы не было чтений одной записи разными читателями, Что бы не получить лост апдейт неконсистентность. если читатели собираются менять то, что начитали, в зависимости от каких то условий, то тогда да. Но в большенстве случаев эксклюзивная блокировка на чтение не нужна. Нужно ставить шаред блокировку, что бы другие читатели могли паралельно читать. Проверять условия, менять ее на экслюзивную, как у писателя и менять. Пока на ресурсе есть шаред блокировка все могут читать паралельно никому не мешая , но изменять никто не может пока все читающие ее не отпустят. приблизительно так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 13:14 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
ДохтаРчитатель уже прочиталИ как читатели узнают какие записи им читать, чтобы не было чтений одной записи разными читателями, Что бы не получить лост апдейт неконсистентность. если читатели собираются менять то, что начитали, в зависимости от каких то условий, то тогда да. Но в большенстве случаев эксклюзивная блокировка на чтение не нужна. Нужно ставить шаред блокировку, что бы другие читатели могли паралельно читать. Проверять условия, менять ее на экслюзивную, как у писателя и менять. Пока на ресурсе есть шаред блокировка все могут читать паралельно никому не мешая , но изменять никто не может пока все читающие ее не отпустят. приблизительно так. Это все понятно. Вопрос не в этом. Если стоит задача раскидать работу по ядрам, то в любом случае то, что делает одно ядро/поток/читатель не должны делать другие ядра/потоки/читатели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 13:45 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
читатель уже прочитал, А нафига это знать писателю если хранилище статичное? Архитектура курсора предусматривает знание о том, какой элемент last pop'ped у каждого курсора. В случае же если хранилище очищается (или его страницы), то это должно предусматриваться архитектурой (или читатель заведомо этот элемент отработал, или же скопировал себе куда - либо). It depends, в общем. Но в любом случае это не функционал ни писателя, ни читателя, а хранилища. Читатели не в курсе про внутреннее строение хранилища, он запрашивает, дай-ка мне указатель на следующий элемент интересующей меня структуры. В одновременном чтении несколькими читателями одной и той же записи не вижу никакой проблемы, хотя в критичных местах это нежелательно, тогда архитектура разбивается на последовательные однопоточные участки с моделью отношений 1P-1C ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 15:10 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
раскидать работу по ядрам, Это вопрос правильной имплементации архитектуры. Когда требование FIFO принципиально, как правило, о распараллеливании речи идти не может или же это по критериям производительности неуместно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 15:11 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
Westtrdдай-ка мне указатель на следующий элемент интересующей меня структуры. А почему вы считаете что тут можно без барьеров обойтись? А если в очередь будет добавлен указатель на структуру, а сама структура еще не синхронизирована по всем ядрам? Барьеры решают именно подобные проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 17:02 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
Westtrdчитатель уже прочитал, А нафига это знать писателю если хранилище статичное? Архитектура курсора предусматривает знание о том, какой элемент last pop'ped у каждого курсора. Хранилище имеет конечный размер и когда-то закончится, значит нужен re-use, и писатель должен знать можно уже перезаписывать элемент или нельзя, т.е. писатель должен знать позицию курсора каждого читателя. А для этого каждый читатель должен будет после каждого сдвига курсора делать store barrier или надеяться на то, что хранилище никогда не переполниться с потерей записей. WesttrdВ одновременном чтении несколькими читателями одной и той же записи не вижу никакой проблемы, хотя в критичных местах это нежелательно, тогда архитектура разбивается на последовательные однопоточные участки с моделью отношений 1P-1C Если задача стоит каждому читателю читать каждую запись, то да - проблемы нет. Но если стоит задача, где писатель должен раздавать задачи, которые должны брать свободные на данный момент читатели - то проблема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 17:14 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovsky, Это не страшно, и решается внутренней логикой. Барьеры негативно влияют на латенси, в данном случае работа на спине часто выгоднее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 17:22 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
Westtrdраскидать работу по ядрам, Это вопрос правильной имплементации архитектуры. Когда требование FIFO принципиально, как правило, о распараллеливании речи идти не может или же это по критериям производительности неуместно. Если все читатели и писатель работают в пределах одного ядра, и распараллеливание не требуется, то может подойдут corutines, которые советует Anatoly Moskovsky. А если читатели и писатель раскиданы по ядрам, и пусть даже все читатели читают одни и те же записи, то в любом случае одни читатели будут опережать других, и кто-то уже все прочитал, а кто-то только первый элемент, и об этом должен будет знать писатель перед тем, как затереть этот элемент при переполнении хранилища. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 17:25 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
переполниться с потерей записей, 1. Хранилище страничное. 2. Вариант повторного использования с очисткой и инвалидацией курсора предусмотрен. Как правило, мои приложения выполняются на системе с достаточным количеством RAM. Обычно в 50 и более раз нежели известная пиковая нагрузка. По второй части соглашусь, но я бы это делал не на стороне писателя, а на стороне читателя чз диспетчера читателей. Тут и батчинг работает и подобного рода вещи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 17:27 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
WesttrdЭто не страшно, и решается внутренней логикой. Что значит не страшно? Вам что все равно какие данные увидит читатель, новые или те которые он по этому адресу в прошлый раз читал? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 17:28 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
читатели и писатель раскиданы, Писателю все равно, что там делают читатели. Вы при создании хранилища устанавливаете стратегию управления страницами. Если страницы повторно используются, писатель имеет значения курсора читателей и время заполнения страницы с опциональной очисткой после разрешенного интервала. Занимается этим фоновый менеджер хранилища. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 17:31 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovsky, Данные после добавления не изменяются. Это FIFO. До приведения записи в консистентное состояние читатель об этом не узнает в принципе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 17:32 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyWesttrdдай-ка мне указатель на следующий элемент интересующей меня структуры. А почему вы считаете что тут можно без барьеров обойтись? А если в очередь будет добавлен указатель на структуру, а сама структура еще не синхронизирована по всем ядрам? Барьеры решают именно подобные проблемы. Вряд ли Westtrd сознается, но что-то подсказывает, что там вся надежда на неявные барьеры при вытеснении кэша, вероятность которых высока на относительно большом размере хранилища. Можно конечно их вызов вручную детерминировать, допустим для условия - каждые 64КБ или 1мкс, но этож надо самому писать, а вытеснение автоматически. Только вот нюанс, есть условия при которых оно не сработает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 17:32 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
WesttrdКак правило, мои приложения выполняются на системе с достаточным количеством RAM. Обычно в 50 и более раз нежели известная пиковая нагрузка. А ну вот я про это и говорил. Тут некоторые вещи упрощаются. А переполнение в принципе не предусмотрено, или при нем включается другая стратегия работы хранилища? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 17:36 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
большом размере хранилища, Это не военная тайна, описано в проектах, то есть тут эксплуатируется тот факт, что при существенной интенсивности потока сообщений это происходит с высокой вероятностью, и в отношении латенси это значительно выгоднее барьеров. Кроме того, думающий админ повесит писателя и читателя этого хранилища на ядра одного процессора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 17:36 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
WesttrdДо приведения записи в консистентное состояние читатель об этом не узнает в принципе. А что вы понимаете под консистентным состоянием записи? Если запись больше одного машинного слова, то даже если вы ее полностью сформировали на одном ядре, то на другом ядре она может быть лишь частично сформирована. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 17:38 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
некоторые вещи упрощаются, В принципе не предусмотрено. Пока не вижу реальным, честно говоря, и не стал разрабатывать подобную архитектуру, но при необходимости архитектура безболезненно и невидимо для пользовательского кода трансформируется к данному функциональному требованию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 17:38 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovsky, Курсор контролируется хранилищем, хранилище осведомлено о том, когда запись переходит в консистентное состояние. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 17:39 |
|
||
|
Потоковый сервер на С++
|
|||
|---|---|---|---|
|
#18+
Westtrdбольшом размере хранилища, Это не военная тайна, описано в проектах, то есть тут эксплуатируется тот факт, что при существенной интенсивности потока сообщений это происходит с высокой вероятностью, и в отношении латенси это значительно выгоднее барьеров. Кроме того, думающий админ повесит писателя и читателя этого хранилища на ядра одного процессора. Это выгодней только потому, что делается редко, но ровно с той же частотой можно и самому делать барьеры. Повесить всех читателей и писателя на одно ядро? Насколько я помню потоки на ядре переключаются примерно раз в 1мс, т.е. это сразу +(1мс X кол-во читателей) к задержке. Синхронизация двух ядер через LLC(L3) с барьером 30нс, т.е. минимум в 30 000 раз меньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 17:44 |
|
||
|
|
start [/forum/topic.php?fid=57&msg=38220831&tid=2020113]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
167ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 284ms |
| 0 / 0 |
