Re: [boost] [lockfree] review

Subject: Re: [boost] [lockfree] review
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-08-09 16:46:27

on Tue Aug 09 2011, Gottlob Frege <gottlobfrege-AT-gmail.com> wrote:

>>
>> Who is "we," Kimosabe?
>>
>
> Almost all other programmers, I think.
>
>> I *really* don't think about code that way.  I generally try to avoid
>> writing code that makes me think about the order in which things happen.
>>
>
> I believe you. But I expect you are the exception.
> So to understand some of the difficulties people have with lockfree, I think
> first you would need to get into the sequential habit, only to understand
> what it is like to break th habit.  Like taking up smoking to know what it
> is like to quit.

umm... nothanks.

> If you instead think more about state/invariants, then the hard part might
> only be giving up areas of protection (member functions/locks) where you can
> break the invariants.  

That's the hard part about lockfree programming.  But most people
shouldn't do that, right?

> And give up some things that would normally be made
> part of the invariant.  Like a pointer managing a list.  

huh?

> Allow the temporary
> state in the middle of an add to be exposed to another operation (in a way
> that all operations can still manage).

To put it more simply, states within the invariant can be exposed, and
other states can't.  Don't make this more complicated than it needs to
be ;-)

> Often the invariants become complicated conditions - "either the pointer is
> valid or the counter is odd or ..." yet you can't check them all in a single
> operation.

Checking is irrelevant, though, isn't it?

> And then sometimes you do use order - ie if I read the counter, then the
> pointer , then re-read the counter, and the counter hasn't changed, then the
> pointer if valid (assuming proper barriers).

To put it more simply, states within the invariant can be exposed, and
other states can't.  [etc]

> Anyhow, I think I strayed off topic. And I'll just go further... It is
> interesting to me to understand how other programmers think. I don't think
> much about order, or invariants, or state; I spend most time thinking about
> how the pieces of code fit together - or more importantly, stay apart.

I do that too, for architectural purposes.  It's a useful way of
thinking, but usually not very useful (to me) for determining
correctness.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com