Информация об изменениях

Сообщение Re[5]: Вопрос по boost lockfree queue от 26.04.2015 21:51

Изменено 26.04.2015 21:54 antropolog

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

A>>я ещё раз повторюсь, представьте что у вас запустился producer и поместил миллион объектов в очередь очень быстро, скажем за 0 секунд,

E>А так не получится. Во-первых, что значит за 0 секунд? Мы же только перед отправкой сообщения получаем timestamp текущий с точностью до наносекунд ( да-да, про погрешность системы знаю, не real time).
пардон, но я уже устал повторять. просто смоделируйте у себя в голове ситуацию, когда consumer стартует на N миллисекунд позже. При этом скорость с которой producer кладёт элементы и consumer достаёт — одинакова, или (я надеялся что вам лучше будет понятно в экстремуме) бесконечно велика (это значит что отработают за 0 секунд).

E>всегда дадут разницу в N наносекунд (хотя бы из за самого вызова ).

да, и это может быть объяснено в разнице между времени старта producer'а и consumer'а. При этом даже если они отрабатывают бесконечно быстро, ваш sum получит гигантские значения.

E>Даже если consumer стартанет раньше, то читать будет нечего. И соответсвенно t2 ( т.е время когда мы получили сообщение ) будет ВСЕГДА больеш t1 (т.е время когда мы записали сообщение).

то что оно всегда больше это очевидно.

попробую аналогией:
100 человек пришло на почту отправить письмо, но почта открылась только через 30 мин. Обслужила 100 человек за примерно полтора часа ( по минуте на человека ). Для каждого человека разница между его приходом на почту и уходом составляет 31 минуту. Вы зачем-то взяли это число и умножили на 100, получили какое-то большое число и ужаснулись. Хотя по факту ужасаться нечему, т.к. скорость обслуживания была 1 человек в минуту, что очень быстро.
Здравствуйте, Engler, Вы писали:

A>>я ещё раз повторюсь, представьте что у вас запустился producer и поместил миллион объектов в очередь очень быстро, скажем за 0 секунд,

E>А так не получится. Во-первых, что значит за 0 секунд? Мы же только перед отправкой сообщения получаем timestamp текущий с точностью до наносекунд ( да-да, про погрешность системы знаю, не real time).
пардон, но я уже устал повторять. просто смоделируйте у себя в голове ситуацию, когда consumer стартует на N миллисекунд позже. При этом скорость с которой producer кладёт элементы и consumer достаёт — одинакова, или (я надеялся что вам лучше будет понятно в экстремуме) бесконечно велика (это значит что отработают за 0 секунд).

E>всегда дадут разницу в N наносекунд (хотя бы из за самого вызова ).

да, и это может быть объяснено в разнице между времени старта producer'а и consumer'а. При этом даже если они отрабатывают бесконечно быстро, ваш sum получит гигантские значения.

E>Даже если consumer стартанет раньше, то читать будет нечего. И соответсвенно t2 ( т.е время когда мы получили сообщение ) будет ВСЕГДА больеш t1 (т.е время когда мы записали сообщение).

то что оно всегда больше это очевидно.

попробую аналогией:
100 человек пришло на почту отправить письмо, но почта открылась только через 30 мин. Обслужила 100 человек за примерно 90 секунд ( по секунде на человека ). Для каждого человека разница между его приходом на почту и уходом составляет ~31 минуту. Вы зачем-то взяли это число и умножили на 100, получили какое-то большое число и ужаснулись. Хотя по факту ужасаться нечему, т.к. скорость обслуживания была 1 человек в секунду, что очень быстро.