Re: Multithreading, callbacks from unknown threads [OT]

[Gaspard Bucher <gaspard@...>]

On Sat, Mar 17, 2012 at 9:41 AM, Ross Bencina <rossb-lists@audiomulch.com> wrote:

On 17/03/2012 7:11 PM, Gaspard Bucher wrote:

[1]
https://github.com/lubyk/lubyk/blob/master/modules/lk/include/lubyk/Fifo.h

With the exception of Visual C++2005 (and maybe later) where "volatile" also implies implicit memory barriers, the above linked code is not guaranteed to be safe.

Atomicity of the read and write pointers is not sufficient.

It is necessary to add processor memory barriers to ensure that the written data in the queue buffer is visible to the reader at the point that the reader sees the write pointer change.

Required memory barriers and barrier pairing will depend on the architecture.

Ross.

Hi Ross,

Thanks for the careful reading. You are right, the following code could run in a different order.

1. Write data in fifo: data_[write_idx_] = data;

2. Notify pipe: write(pipe_fd_[1], "", 1);


3. Lua 'select' returns... yield the coroutine... and pop: T *data = data_[read_idx_];

I can imagine the CPU reordering and doing (2) and then yielding another thread locking the thread before (1). What if I do

if(data_[write_idx_] == data)

  write(pipe_fd_[1], "", 1);

Does this ensure that the CPU cannot reorder (2) before (1) ?

Cheers,

                                                               Gaspard