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

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

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

A> через полсекунды (условно, мало ли как поток запланировался операционкой) запустился consumer, выгреб миллион объектов опять же очень быстро, за 0 секунд. Что вы в итоге насчитаете? У вас "latency" будет полсекунды для каждого элемента в очереди, что, очевидно, бессмысленная информация, т.к. в данном случае может лишь свидетельствовать о более позднем старте consumer'а по отношению к producer'у.
В итоге, должно все правильно посчитаться. Т.е мы вычитали сообщение ( а вычитать мы можем только в том случа если его producer УЖЕ положил ). И тут же берем у системы текущее время. Т.е груго говоря, два вызова подряд:

clock_gettime( CLOCK_REALTIME,  &time1 ); // это в procuer потоке
clock_gettime( CLOCK_REALTIME,  &time2 ); // это в consumer потоке

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


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