Здравствуйте, Аноним, Вы писали:
Если про кэши ядра я оговорился, то с кэшами процессоров не совсем понятно
Тогда если так хорошо умельцы из MS придумали
Thread.VolatileRead и Thread.VolatileWrite упомянутые в той статье.
http://msdn.microsoft.com/ru-ru/library/system.threading.thread.volatileread.aspx
http://msdn.microsoft.com/ru-ru/library/system.threading.thread.volatilewrite.aspx

Здравствуйте, Аноним, Вы писали:

На обиженных воду . Мне самому интересно разобраться. О том что ты написал я сам смутно помнил по этому и сомневался
Но вот такие комментарии http://msdn.microsoft.com/ru-ru/library/th4b7fw3.aspx
их только развивают. Никакой конкретики, если только процессоронезависимость Net, Ява

Здравствуйте, Аноним, Вы писали:

На обиженных воду . Мне самому интересно разобраться. О том что ты написал я сам смутно помнил по этому и сомневался
Но вот такие комментарии http://msdn.microsoft.com/ru-ru/library/th4b7fw3.aspx
их только развивают. Никакой конкретики, если только процессоронезависимость Net, Ява

Здравствуйте, Пельмешко, Вы писали:


П>А перечитайте начало топика, посмотрите какие требования к логике представлены нужны и что подсказал Undying по П>поводу постоянного создания потоков.
давайте по порядку

П>Потребовалось сделать велосипед со следующим поведением:
П>* Класс олицетворяет собой очередь сообщений.
П>* В класс из нескольких потоков поступают сообщения, а так же есть подписчики на эти сообщения.
П>* Класс должен поочерёдно извлекать сообщения из очереди и отправлять их подписчикам события.и
тут все требования, как я понимаю, удовлетворены, т.к. мое предложение по модификации вашего кода не касается этих требований.

П>* Между отправками сообщений должен соблюдаться заданный временной интервал.
соблюдается
П>* При отсутствии сообщений в очереди не должно создаваться никаких накладных расходов (например, в виде постоянно П>проверяющего очередь потока).
В моем случае нет собщений — нет ни одного работающего потока, в вашем случае есть — ожидающий добавления сообщения.
С этой точки зрения мое предложение лучше.
П>* В очереди может быть достаточно много сообщений, поэтому реализация очереди не должна плодить потоки на каждое.
Обращаю ваше внимание на формулировку — в моем случае потоки не плодятся. Покажите, где создается поток?
П>* Должна быть возможность приостановить/возобновить отправки.
соблюдается

П>

П>                lock(syncRoot)
П>                {
П>                    Thread.Sleep(interval);
П>                }
П>

Даже не знаю что Вам на ЭТО ответить...

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

Здравствуйте, Arboz, Вы писали:
П>>* Между отправками сообщений должен соблюдаться заданный временной интервал.
A>соблюдается
Ага, перед отправкой первого так же, хотя он ни в чём не виноват и может быть быть отправлен без задержки по определению (требуется интервал между отправками сообщений).

П>>* При отсутствии сообщений в очереди не должно создаваться никаких накладных расходов (например, в виде постоянно П>проверяющего очередь потока).
A>В моем случае нет собщений — нет ни одного работающего потока, в вашем случае есть — ожидающий добавления сообщения.
A>С этой точки зрения мое предложение лучше.

Ага, Вы забиваете пул задачами, потоки не "плодятся"
А зафиг тогда очередь? Почему сообщение отправителю через state не отправить?
В конце-концов, где гарантия, что пул выдержит 100000 сообщений?

A>Ну уж скажите что-нибудь. Аргументированное, пожалуйста.

                lock(syncRoot)
                {
                    Thread.Sleep(interval);
                }

А как Вам такой сценарий: работа потока может быть прервана после выхода из лока, и следующий SenderJob может пройти лок и отправить следующее сообщение первым, то есть не будет соблюдаться порядок? Маловероятно? А если подписчик на событие долго (дольше интервала) обрабатывает сообщение?

И вообще это выглядит очень странно: лок ресурса на время.
Я считаю это не интуитивно понятным и использованием lock не по назначению.
Вы часто такое применение lock видели?

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Аноним, Вы писали:

S> На обиженных воду . Мне самому интересно разобраться. О том что ты написал я сам смутно помнил по этому и сомневался
S>Но вот такие комментарии http://msdn.microsoft.com/ru-ru/library/th4b7fw3.aspx
S>их только развивают. Никакой конкретики, если только процессоронезависимость Net, Ява

В своё время отсутствие чёткой информации от MS и сподвигло меня на разбирательство с современным состоянием дел

По поводу сказанного в MSDN — ну что тут скажешь? За комментариями надо-бы обращаться к авторам. Со своей стороны могу только предположить:
NET позиционируется как полностью кроссплатформенная. Исходя из этого можно предположить, что возможно появление среды исполнения NET для некой гипотетической платформы, в которой управления кэшами производится программно, и на этот случай разработчики специально оговаривают, что возьмут эту задачу на себя. Хотя лично мне несколько затруднительно представить, как может функционировать такая многопроцессорная система без синхронизации кэшей.

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

первое, Рихтер:

Однако кэш-линии сильно усложняют обновление памяти в многопроцессорной среде. Вот небольшой пример:

1. Процессор 1 считывает байт, извлекая этот и смежные байты в свою кэш-линию.
2. Процессор 2 считывает тот же байт, а значит, и тот же набор байтов, что и процессор 1; извлеченные байты помещаются в кэш-линию процессора 2.
3. Процессор 1 модифицирует байт памяти, и этот байт записывается в его кэш линию. Но эти изменения еще не записаны в оперативную память.
4. Процессор 2 повторно считывает тот же байт Поскольку он уже помещен в кэш-линию этого процессора, последний не обращается к памяти и, следова тельно, не «видит" новое значение данного байта.

Такой сценарий был бы настоящей катастрофой. Но разработчики чипов прекрасно осведомлены об этой проблеме и учитывают её при проектировании своих процессоров В частности, когда один из процессоров модифицирует байты в своей кэш линии, об этом оповещаются другие процессоры, и содержимое их кэш-линий объяв ляется недействительным. Таким образом, в примере, приведенном выше, после изменения байта процессором 1, кэш процессора 2 был бы объявлен недействительным. На этапе 4 процессор 1 должен сбросить содержимое своего кэша в оперативную память, а процессор 2 — повторно обратиться к памяти и вновь заполнить свою кэш линию Как видите, кэш-линии, которые, как правило, увеличивают быстродействие процессора, в многопроцессорных машинах могут стать причиной снижения произ водительности.

И вот неплохая статья об общих принципах построения кэшей, правда о многопроцессорности там не упоминается.

Здравствуйте, Пельмешко, Вы писали:

Здравствуйте, jedi, Вы писали:

Господа, есть предложение придерживаться при общении хотя-бы некоторого подобия норм профессиональной этики. Аргументы типа "сам дурак" возможно и котируются в дворовой компании, но в среде профессионалов они вызывают некоторое удивление и недоумение, мягко говоря.

Здравствуйте, jedi, Вы писали:

J>Здравствуйте, <Аноним>, Вы писали:

А>>Здравствуйте, Serginio1, Вы писали:

А>>Признаться, я не понял, что нужно смотреть, и что значит "лок соответствует критической секцией" В WinApi мы просто вызываем EnterCriticalSection, при чём тут лок? Вы можете с успехом заменить EnterCriticalSection на WaitForSingleObject(Semaphore), ничего не поменяется. Здесь нет никаких иницируемых системой сбросов кэша, этого просто не нужно. Когерентность обеспечивается механизмом самих кэшей, на уровне железа. Вообще принудительный сброс кэша нужен только в очень редких, весьма экзотических, случааях.

J>АААА.... Я хочу такое железо как у него. Почему мне не такое продали???

Уважаемый, Аноним, приношу извинения. Неправильно понял и сморозил глупость. Обещаю исправиться

Тут другой вопрос возникает. Понятно, что когерентность кешей хорошо работает в современнх многоядерных процах, где все процы на одном камне. А вот интересно как обстоит дело с кешами в архитектурах, где процы реально раздельные. Ведь процессоры "далеко" и если они начнут следить за когерентностью кешей, не убьет ли это саму идею кеша? Или таких архитектур просто нет на сегодняшний день?

Здравствуйте, Пельмешко, Вы писали:

П>Работа устраивает, проблем не наблюдается, но хочется довести до ума чтобы "уж наверняка"...

Так-то нормально. Но если завтра задача усложнится, например, наряду с обычными появятся срочные сообщения, которые нужно будет отправлять мгновенно, то как ты ее будешь решать? Thread.Sleep(interval) там уже нельзя будет использовать.

Еще можешь terminate добавить и Dispose, как в примере Анонима, чтобы была возможность штатного завершения потока.

Здравствуйте, jedi, Вы писали:

J>Уважаемый, Аноним, приношу извинения. Неправильно понял и сморозил глупость. Обещаю исправиться

Пустяки, забудим. У всех у нас есть нервы, и далеко не всегда этот факт идёт нам на пользу

J>Тут другой вопрос возникает. Понятно, что когерентность кешей хорошо работает в современнх многоядерных процах, где все процы на одном камне. А вот интересно как обстоит дело с кешами в архитектурах, где процы реально раздельные. Ведь процессоры "далеко" и если они начнут следить за когерентностью кешей, не убьет ли это саму идею кеша? Или таких архитектур просто нет на сегодняшний день?

Ну почему-же, есть.

Я знакомился с данным вопросом несколько лет назад, и всё написанное ниже базируется не на точных знаниях, а на воспоминаниях, на которые, к сожалению, не всегда можно полностью положиться

Не стоит забывать, что многопроцессорные системы появились намного раньше, чем многоядерные процессоры. В доисторические времена, когда компьютеры были большими, каждый производитель решал эту проблему по-своему. Появление новой модели было достаточно редким явлением, и особой необходимости в едином стандарте просто не было. Но потом появились достаточно серьёзные модели микропроцессоров. Однако эти первые модели обладали всё-таки ограниченной вычислительной мощьностью. Сам собой встал вопрос об увеличении мощности компьютеров путём создания многопроцессорных систем, благо такой опыт уже был накоплен. Тогда и возникла идея разработки унифицированного протокола синхронизации кэшей, что и было сделано где-то в середине 90-х. Смутно припоминаю, что вроде как он базировался на каком-то более раннем протоколе, но это не факт. Этот протокол был принят всеми производителями и они стали включать его поддержку в свои модели. Физически, насколько помню, у процессоров предусмотрена специальная внешняя шина, по которой контроллеры кэшей договариваются друг с другом. Ну а когда появились многоядерники, то этот протокол был реализован и для них, что было вобщем-то даже проще, чем для многопроцессорного варианта.

Убить идею кэша конечно можно, о чём и Рихтер пишет, но это уже зависит от автора программы. Нужно просто учитывать эти особенности при реализации многопоточности, уделяя достаточно внимания эффективности кода. В частности, весьма желательно минимизировать взаимодействие потоков между собой. Когда каждый из потоков имеет дело со своим обособленным набором данных, то и вероятность инвалидации линейки в кэше сводится к минимуму. Да и производители чипов не сидят сложа руки, работают над оптимизацией алгоритмов управления кэшем. В современных процессорах линия кэша обычно имеет размер 32 или 64 байта, при её инвалидации требуется обновить только эти байты, а не весь кэш. Это, кстати напоминает нам а крайней желательности выравнивания переменных на эту границы — если часть структуры окажется в одной, а другая в другой линейке, то придётся обновить в два раза больше байтов. Но в NET, я думаю, это не столь актуально, среда исполнения наверняка учитывает такие нюансы. Двухуровневый кэш тоже значительно снижает остроту проблемы, позволяя второму уровню обмениваться памятью одновременно с обработкой процессором данных.

Так что не всё так печально, как это может показаться на первый взгляд Но учитывать такие тонкости всё-таки стоит.

Здравствуйте, <Аноним>, Вы писали:

А>Не стоит забывать, что многопроцессорные системы появились намного раньше, чем многоядерные процессоры. В доисторические времена, когда компьютеры были большими, каждый производитель решал эту проблему по-своему. Появление новой модели было достаточно редким явлением, и особой необходимости в едином стандарте просто не было. Но потом появились достаточно серьёзные модели микропроцессоров. Однако эти первые модели обладали всё-таки ограниченной вычислительной мощьностью. Сам собой встал вопрос об увеличении мощности компьютеров путём создания многопроцессорных систем, благо такой опыт уже был накоплен. Тогда и возникла идея разработки унифицированного протокола синхронизации кэшей, что и было сделано где-то в середине 90-х. Смутно припоминаю, что вроде как он базировался на каком-то более раннем протоколе, но это не факт. Этот протокол был принят всеми производителями и они стали включать его поддержку в свои модели. Физически, насколько помню, у процессоров предусмотрена специальная внешняя шина, по которой контроллеры кэшей договариваются друг с другом. Ну а когда появились многоядерники, то этот протокол был реализован и для них, что было вобщем-то даже проще, чем для многопроцессорного варианта.

А>Убить идею кэша конечно можно, о чём и Рихтер пишет, но это уже зависит от автора программы. Нужно просто учитывать эти особенности при реализации многопоточности, уделяя достаточно внимания эффективности кода. В частности, весьма желательно минимизировать взаимодействие потоков между собой. Когда каждый из потоков имеет дело со своим обособленным набором данных, то и вероятность инвалидации линейки в кэше сводится к минимуму. Да и производители чипов не сидят сложа руки, работают над оптимизацией алгоритмов управления кэшем. В современных процессорах линия кэша обычно имеет размер 32 или 64 байта, при её инвалидации требуется обновить только эти байты, а не весь кэш. Это, кстати напоминает нам а крайней желательности выравнивания переменных на эту границы — если часть структуры окажется в одной, а другая в другой линейке, то придётся обновить в два раза больше байтов. Но в NET, я думаю, это не столь актуально, среда исполнения наверняка учитывает такие нюансы. Двухуровневый кэш тоже значительно снижает остроту проблемы, позволяя второму уровню обмениваться памятью одновременно с обработкой процессором данных.

А>Так что не всё так печально, как это может показаться на первый взгляд Но учитывать такие тонкости всё-таки стоит.

Спасибо, познавательно

P.S. Вы бы зарегистрировались, я думаю народ бы отблагодарил оценками за информацию

Здравствуйте, Пельмешко, Вы писали:

П>Ага, перед отправкой первого так же, хотя он ни в чём не виноват и может быть быть отправлен без задержки по определению (требуется интервал между отправками сообщений).
Поставьте, так понравившеюся вам секцию (lock + Sleep), после отправки сообщения,
тогда будет точное удовлетворение этому условию.

П>Ага, Вы забиваете пул задачами, потоки не "плодятся"
Да, не плодятся.
П>А зафиг тогда очередь? Почему сообщение отправителю через state не отправить?
Очередь гарантирует заданную последовательность обработки ваших сообщений.
Последовательность помещение делегатов в ThreadPool не гарантирует порядок их выполнения, и хотя он сейчас FIFO,

Проблема, которую требуется решить, в первую очередь требует понимания того, как работает подготовка к отправке в ThreadPool. Внутренне, он поддерживает очередь переданных ему рабочих элементов. Когда поток в пуле доступен для исполнения работы, он возвращается к этой очереди и вытягивает из нее следующий элемент. Порядок, в котором происходит эта обработка, не задокументирован и на него совершенно точно не следует полагаться (поскольку он может измениться и, скорее всего, изменится в будущих версиях.
Сейчас он реализован очень просто: очередь «первым вошел – первым вышел» (first-in-first-out – FIFO).

П>В конце-концов, где гарантия, что пул выдержит 100000 сообщений?
В документации нет упоминаний про ограничения... Тем более что —

Сейчас он реализован очень просто: очередь «первым вошел – первым вышел»

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

П>А как Вам такой сценарий: работа потока может быть прервана после выхода из лока, и следующий SenderJob может пройти лок и отправить следующее сообщение первым, то есть не будет соблюдаться порядок?
Порядок гарантируется выбранной структурой хранения — а именно очередью, с синхронизированным доступом.

П>А если подписчик на событие долго (дольше интервала) обрабатывает сообщение?
Да, подобной проблемы мой код не решает. Так же как и ваш.


П>И вообще это выглядит очень странно: лок ресурса на время.
П>Я считаю это не интуитивно понятным и использованием lock не по назначению.
П>Вы часто такое применение lock видели?
Это искусственный таймаут — я не вижу тут никакого совсем никакого криминала.

Здравствуйте, Undying, Вы писали:

U>Здравствуйте, Пельмешко, Вы писали:

П>>Работа устраивает, проблем не наблюдается, но хочется довести до ума чтобы "уж наверняка"...

U>Так-то нормально. Но если завтра задача усложнится, например, наряду с обычными появятся срочные сообщения, которые нужно будет отправлять мгновенно, то как ты ее будешь решать?
А решать буду так: ThreadPoolPriority
Да, Sleep-а не будет

U>Еще можешь terminate добавить и Dispose, как в примере Анонима, чтобы была возможность штатного завершения потока.
Это я оставил на откуп автору.

Здравствуйте, Arboz, Вы писали:

A>А решать буду так: ThreadPoolPriority

А зачем нужны такие сложности?

Здравствуйте, Пельмешко, Вы писали:

П>Ага, Вы забиваете пул задачами, потоки не "плодятся"
П>А зафиг тогда очередь? Почему сообщение отправителю через state не отправить?
П>В конце-концов, где гарантия, что пул выдержит 100000 сообщений?

Выдержит, так очередь ограничена только памятью. Другой вопрос, что ограничить эту очередь,
семафорами.

Здравствуйте, Undying, Вы писали:

U>Здравствуйте, Arboz, Вы писали:

A>>А решать буду так: ThreadPoolPriority

U>А зачем нужны такие сложности?
Да не сказать:
В нашем случае — две очереди, вместо одной _queues

_priorityQueue = new Queue<string>(),
_standardQueue = new Queue<string>();

и логика

private void SenderJob(object state)
{
            sendEvent.WaitOne();

            string message;
            lock(_priorityQueue)
            {
              message = (_priorityQueue.Count > 0 ? 
                _priorityQueue : _standardQueue).Dequeue();
            }

            if (message != null)
            {
                Action<string> receiver = this.MessageReceived;
                if (receiver != null) receiver(message);

                // :) а таймаут оставляем
                lock(syncRoot)
                {
                    Thread.Sleep(interval);
                }

            }
}

public void EnqueueMessage(string message, bool priority)
{
        lock(_priorityQueue) {
            (isPriority ? _priorityQueue : _standardQueue).Enqueue(qc);
        }

        ThreadPool.QueueUserWorkItem(SenderJob, null);
}

Здравствуйте, Arboz, Вы писали:

A>В нашем случае — две очереди, вместо одной _queues

И где в приведенном коде срочные сообщения? Срочные это значит, что они должны быть отправлены как можно быстрее. Значит, во-первых, если мы напихали в очередь 10 срочных сообщений все они должны быть отправлены друг за другом без всяких пауз. Во-вторых, если поток отправил несрочное сообщение и теперь спит установленный для несрочных сообщений интервал, то при появлении срочного сообщения поток должен проснуться и немедленно обработать срочное сообщение. В твоем коде я не вижу никакой разницы в обработке срочных и несрочных сообщений.

Здравствуйте, Undying, Вы писали:

U>Здравствуйте, Arboz, Вы писали:

A>>В нашем случае — две очереди, вместо одной _queues

U>И где в приведенном коде срочные сообщения? Срочные это значит, что они должны быть отправлены как можно быстрее. Значит, U>во-первых, если мы напихали в очередь 10 срочных сообщений все они должны быть отправлены друг за другом без всяких пауз. U>Во-вторых, если поток отправил несрочное сообщение и теперь спит установленный для несрочных сообщений интервал, то при U>появлении срочного сообщения поток должен проснуться и немедленно обработать срочное сообщение.

Опять же — не вижу проблемы.
заводим еще

private static readonly EventWaitHandle _prior = new EventWaitHandle(false, EventResetMode.ManualReset);

далее

private void SenderJob(object state)
{
            sendEvent.WaitOne();

            string message;
            bool isPriority;
            lock(_priorityQueue)
            {
              //первыми выбираем приоритетные сообщения
              message = (_priorityQueue.Count > 0 ? _priorityQueue : _standardQueue).Dequeue();
              isPriority = _priorityQueue.Count > 0;
              //если еще есть приоритетные, то сбрасываем ожидание, иначе закрываем кран
              if(isPriority) 
                 _prior.Set()
              else
                 _prior.Reset();
            }
            
            if (message != null)
            {
                //вызов обработчиков
                Action<string> receiver = this.MessageReceived;
                if (receiver != null) receiver(message);

       
                //если это обычное сообщение, то таймаут
                if(!isPriority)
                {
                    lock(syncRoot)
                    {
                       _prior.WaitOne(interval);
                    }
                }

            }
}

public void EnqueueMessage(string message, bool isPriority)
{
        lock(_priorityQueue) {
            (isPriority ? _priorityQueue : _standardQueue).Enqueue(message);
        }

        if(isPriority)
             _prior.Set();

        ThreadPool.QueueUserWorkItem(SenderJob, null);
}

U>В твоем коде я не вижу никакой разницы в обработке срочных и несрочных сообщений.
срочные имеют более высокий приоритет, т.к. отправляются первыми

О чем мы спорим? Подобным подходом возможно реализовать любую логику.

Здравствуйте, <Аноним>, Вы писали:

...

А>Да ничто вобщем-то не мешает, просто как-то нелогично. А скорее просто не привычно

А>PS RAM всё-таки принято применять к чисто ОЗУ, к регистрам процессоров оно ка-бы не совсем подходит.
Ты не понял , я имел в виду, что процессору пофиг, какое там поле обрабатываться должно, он с RAMой работает.
Скажем так: регистр — просто место обработки, этакий workplace. Сейчас в нём одно, через милисекунду — другое. Конечно, регистр — не RAM .

Здравствуйте, Кондраций, Вы писали:

К>Здравствуйте, <Аноним>, Вы писали:

К>...

А>>Да ничто вобщем-то не мешает, просто как-то нелогично. А скорее просто не привычно

А>>PS RAM всё-таки принято применять к чисто ОЗУ, к регистрам процессоров оно ка-бы не совсем подходит.
К>Ты не понял , я имел в виду, что процессору пофиг, какое там поле обрабатываться должно, он с RAMой работает.
К>Скажем так: регистр — просто место обработки, этакий workplace. Сейчас в нём одно, через милисекунду — другое. Конечно, регистр — не RAM .

Действительно, не понял. У меня в тот день вообще что-то понималка сильно глючила