[zeromq-dev] race condition in pipe?
dhammika at asperasoft.com
Mon Apr 13 08:32:24 CEST 2009
Yes, writer_terminated runs first.
In writer_terminated() we send terminate_pipe_ack and reset
source_thread and source_engine pointers.
But the reader thread could delete pipe object before we update these pointers.
void zmq::pipe_t::writer_terminated ()
// Send termination acknowledgement to the pipe reader.
cmd.init_engine_terminate_pipe_ack (destination_engine, this);
source_thread->send_command (destination_thread, cmd);
<<<<< reader receives teminate_pipe_ack and deletes this pipe object >>>>>
source_thread = NULL;
source_engine = NULL;
Do you think this is possible?
On Sun, Apr 12, 2009 at 10:17 PM, Martin Sustrik <sustrik at fastmq.com> wrote:
> Hi Dhammika,
>> writer_terminated in pipe sends term_ack to other thread and proceeds
>> to reset pointers.
>> However, on receiving term_ack api_thread deletes the pipe in
>> terminate_pipe_ack (in engine_base.hpp)
>> I think its possible to have a race condition here, and
>> writer_terminated to could actually endup writing to deallocated
> This is probably the most complex part of the code. I've uploaded some
> sequence diagrams here:
> I believe that writer_terminated gets called before reader_terminated
> (deallocation of the pipe) in all cases.
> Still, if you've found a race condition, write down exact sequence of steps
> that causes the problem. We can start looking for the solution then.
More information about the zeromq-dev