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