[zeromq-dev] race condition in pipe?

[Martin Sustrik]

Good spot!

Fixed in revision 1341.

Martin

Dhammika Pathirana wrote:
> 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
>>
>>