qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Rdma IO state transitions [Was: AsynchIO state transition]
Date Tue, 14 Sep 2010 14:47:27 GMT
>>From the description it seems that you are asking about the RDMA
AsynchIO state transition. You should have said that as part of the
description as it is entirely different from and other part of the IO
system of qpid.

On Mon, 2010-09-13 at 15:04 -0700, Danny Guo wrote:
> Hi all,
> Is there a simplistic way to understand the state transition? I got confused
> with the oldState, newState and “action”.

I find that drawing a state diagram helps me to understand what's going
on - I find I need to do this about every 6 months (and I wrote the code
in question).

The state machine here may be a little more confusing than usual state
machine code because it uses a lockless state variable (some performance
measurements we took after the initial implementation with locks
indicated that this lock was heavily contended).

This is why we loop around trying to change the state until it "sticks".
It also explains why we don't actually carry out the action in the
switch statement but instead record what we should do and only do it
when we've successfully set the state (because we don't want to "back
out" the action from a failed transition).

The entire purpose of this state machine is to arbitrate between calls
to dataEvent() and notifyPendingWrite() which can happen on different
threads at the same time.

> My understanding is that
> 1) postWrite only in IDLE state;
> 2) stop IO when a) there’s no outstanding write (DRAINED), or 2) it's in
> 3) queue up Write requests in any other state and wait until IDLE to drain
> the write queue.

Draw the state transition diagram to see what's possible in what state,
this description doesn't really capture it (ie I don't think it's

> What confuses me is that:
>  1) why do we need the Notify/Pending_notify/Pending_data/Data state.
> 2) why do we need to use state.get() to set both oldState and newState? The
> state transition code should be locked anyway.

No locks are used here at all as described above: state is an atomic
variable, and youi need .get() to access its value.

> 3) when will state.boolCompareAndSwap(oldState, newState) ever return false?

In the case of this code if another thread has changed the atomic
variable whilst you were computing the new state.


Is a pointer with some information about this.

I believe that use a lockless state machine design is safe from ABA
problems (at least in this case) because the state actions only ever
depend on the current state and never on the transition path.


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message