Re: [boost] [lockfree] Review

Subject: Re: [boost] [lockfree] Review
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2011-08-09 01:00:35

On Monday, August 8, 2011, Helge Bahmann <hcb_at_[hidden]> wrote:
>
>
> On Saturday 06 August 2011 08:30:05 Gottlob Frege wrote:
>> On Wed, Aug 3, 2011 at 7:06 AM, Helge Bahmann <hcb_at_[hidden]>
wrote:
>> >> > - if the data is changing (through a writable mapping by someone
else
>> >> > to the
>> >> > page), then you have some sort of producer-/consumer-problem and
that
>> >> > is
>> >> > trivialley solvable with word-sized atomic operations
>> >>
>> >> Really?
>> >
>> > yes, really
>> >
>> > keep an "even" and an "odd" copy of your data structure, keep an
>> > atomically readable "generation counter" -- on access, read the
>> > generation counter, read the data (depending on parity of generation
>> > counter), read the generation counter again
>> >
>> > if it changed, start over. if it didn't change, you have your data; on
>> > modification, update generation counter as appropriate (if you are
>> > paranoid about counter overflows, you can repeat a similar trick with
the
>> > counter itself)
>>
>> This is single producer / single consumer?  (probably works for spmc
>> too).  But not multi-producer.  Right?
>
> right,

OK, I was just checking that I understood what you meant.

> but you can always build consensus on your data somewhere else for
> multiple producers, then build consensus on who gets to "commit" the data
to
> the pure consumers (probably this will work in a single step). While this
> adds another "copy" operation to the producer path, a few stores are lost
in
> the noise compared to even a single interlocked cmpxchg.
>

Consensus building sounds like something that might require atomic ops of
its own, but I get the idea.

> Helge
>

Tony