Hi,
The version of Concurrency Kit that you're using is ancient. Could you
please use the latest version? We can work from there. However, it
seems what you're experiencing is a side effect of jitter / etc... and
not ck_ring itself (which is extremely fast).
On Thursday, May 22, 2014 10:08:35 PM UTC+5:30, sbahra wrote:Hi,
The version of Concurrency Kit that you're using is ancient. Could you
please use the latest version? We can work from there. However, it
seems what you're experiencing is a side effect of jitter / etc... and
not ck_ring itself (which is extremely fast).
Hi Aval,
If you are going to be enqueuing pointers then you should be passing
in a pointer to storage space whose lifetime matches that of the
lifetime of the object. In this case ck_ring_buffer_t has sufficient
storage for a buffer of pointers. In your example, it appears you are
trying to store the object value directly in the ring. I do not
recommend doing that at 64 bytes or at least make sure to benchmark
things. If you want additional examples, look at
http://facebook.github.io/libphenom/
If you wish to store the objects directly inside of the ring buffer
(which may not be beneficial at 64 bytes an entry) then please use the
upper-case family of ck_ring beginning with CK_RING_PROTOTYPE. This
defines a ring whose individual storage elements are of the type of
the value you are attempting to store.
Hi Aval,
If you are going to be enqueuing pointers then you should be passing
in a pointer to storage space whose lifetime matches that of the
lifetime of the object. In this case ck_ring_buffer_t has sufficient
storage for a buffer of pointers. In your example, it appears you are
trying to store the object value directly in the ring. I do not
recommend doing that at 64 bytes or at least make sure to benchmark
things. If you want additional examples, look at
http://facebook.github.io/libphenom/
If you wish to store the objects directly inside of the ring buffer
(which may not be beneficial at 64 bytes an entry) then please use the
upper-case family of ck_ring beginning with CK_RING_PROTOTYPE. This
defines a ring whose individual storage elements are of the type of
the value you are attempting to store.
Hi Michael,
Really depends on use-case, requires you measure it. Just need to make sure that copy overhead is smaller than dereference overhead (and sometimes expensive overhead of allocator).
Besides correctness issues here, granularity of gettimeofday is unclear nor is cost relative to the dequeue.