[zeromq-dev] race condition in pipe?

[Dhammika Pathirana]

Hi Martin,

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.
    command_t cmd;
    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
>> memory.
>
> This is probably the most complex part of the code. I've uploaded some
> sequence diagrams here:
>
> http://www.zeromq.org/docs:shutdown
>
> 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.
>
> Martin
>
>