[zeromq-dev] libzmq and helgrind

Thomas Rodgers rodgert at twrodgers.com
Tue Aug 19 04:53:54 CEST 2014


Hmmmm, I just ran this on my *nix box (Ubuntu 14.04, gcc4.8) with helgrind
and I get no races in zmq::msg_t::close() reported, nor do I see anything
in the implementation of zmq::msg_t::close() that's likely racey in
practice.

On Monday, August 18, 2014, Michi Henning <michi at triodia.com> wrote:

> Hi Thomas,
>
> thanks for the quick answer!
>
> > If the message size exceeds the 'vsm' message length limit, it becomes
> an 'lmsg'.  This type is indeed heap allocated, and when the enclosing
> message type is copied, the copies share the reference to the underlying
> heap allocation (and any potential data races that come along with that).
> The lifetime is controlled by an atomic refcount.
> >  zmq::msg_t::close() should not create a race as it relies on the atomic
> refcount dropping to zero before freeing the heap block.
> >
> > Access to the actual message data() could potentially create a data
> race, but the receiving side should never have access to a message that is
> still being written by a background thread.
>
> OK, so that sounds like the races on data() and memcpy() are bogus. What
> about the close() race though? I wasn't expecting to see that one.
>
> Cheers,
>
> Michi.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140818/4b0fdb32/attachment.html>


More information about the zeromq-dev mailing list