First, I represent the game state with a product type of Board and Side (only conceptually, but without actual code):

type Side = Black | White | None
type Coordinate = (Int, Int) -- from (0,0) to (7,7)
type Board = [Char] -- 64 of them!
-- | Game state type alias
type GameState = (Board, Side)

n = "_XO" -- visually they are reprensed these chars.

Then I implemented a helper function v for checking the number of flips per each line. There are 8 different directions the line can go, they are all enumerable by a StepCoordinate type.

-- number of steps (-1,0 or 1) in each direction to represent 8 different directions.
type StepCoordinate = (Int, Int)

-- | Check number of flips for one single direction
v :: GameState -> (GameState, Int) -> Coordinate -> StepCoordinate -> State
  -> (GameState, Int)
v savedGameState (currentGameState, nFlips) cor stepCor state
  -> (newGameState, nFlips)

Then the % operator for trial plays. Because this is used so often, the usage of this binary operator saves a lot of spaces!

(%) :: GameState -> Coordinate -> (GameState, Int)
(%) inGameState -> cor -> (outGameState, nFlips)

The q function moves the game state to the next round.

-- | Play and move to next round
q :: GameState -> Coordinate -> GameState
q currentGameState -> cor -> nextRoundGameState

The z function starts the game in the IO monad.

-- | Start game
z :: Side -> GameState -> IO ()
z humanSide (initialBoard,currentSide)

The e function is the game strategy for the AI:

-- | Strategy function!
e :: GameState -> GameState

It should use the q function to move the game state forward.

There are three game strategies attempted during the code jam:

1. A naive strategy that finds the first possible move.
2. A greedy strategy that finds the immediate move that flips the most pieces.
3. A MiniMax strategy that tries to play the game with a few levels of depth with MiniMax decision rules.

I will enlist the code of (3) here. And because of its minified nature, it looks pretty hideous, I admit:

g h a=f(\c e->i e>i c?e$c)(-65*h,(0,0))$
        (\((b,p),d)->(h*(h*p==0?j a`c`i b$i$g(div h(-2))b),d))&
        (((,)=<<(a%))&k r);
e a=q a.j$g 4a

Here g 4a is a recursive function starting with 4, and it oscillates between positive ("max" stage) and negative ("min" stage) and halves at the same time (g -2a, then g 0a). This is a trick to use a single number to represent the stage and depth limit of the minimax process.

The evaluation function is kept simple; the more flips, the better. In a better strategy, certain pieces are worth more (at the corner or at the side).

As the first step to expand the depth of the protocol, I am happy to announce that the first yellowpaper of its series about the most fundamental part of the Superfluid idea is now available: "Denotational Semantics of General Payment Primitives, and Its Payment System."

The paper first explores the foundation of modern payment systems, which consists of a money distribution model, payment primitives, payment execution systems of financial contracts, and different forms of money mediums. Then the paper uses denotational semantics to formally define payment primitives for modern payment systems. Lastly, this paper also includes an overview of the Superfluid Protocol, a reference implementation of the payment primitives, and its payment system.

Here are some of the topics future yellowpapers will explore:

• Composing payment primitives of modern payment systems.
• A deterministic buffer-less modern payment execution environment.
• A note (EUTXO) based modern payment execution environment.

These are some cross-cutting concerns of modern payment systems; they form a stronger foundation to build future Superfluid Protocol implementations.

Here is a sneak peek into how that next generation Superfluid Protocol implementation could look like:

We will still maintain our strong focus on EVM blockchains and start to work towards the EVMv2 Superfluid Protocol.

At the same time, bringing ideas behind the Superfluid Protocol everywhere is our longer-term dream. Therefore, to avoid the risk of premature favoritism, we shall not mention any particular blockchains; nonetheless, it suffices to say that a grant-seeking approach will be favored when exploring other chain implementations.

For the purpose of this article, the index is limited to being proportional distribution index. In this form, each subscriber subscribes to a number of units of the index. And number of units determines the proportional amounts subscribers should receive from the distributions. You can think of dividend payments from Microsoft to its share holders is such example, where the number of shares at ex-div date determines your dividend payout amount at the payout date.

The name of the semantic function for subscribers is updateSubscription.

The function of which how the publisher distributes money is the distribution curve.

Distribution curve can be any arbitrary continuous function, but for a practical solvency response system (in this case, a system that can check if the publisher still have positive balance left), it is desirable to have a distribution curve that is monotonically non-decreasing.

However, instant distribution is a special case even though it is not a continuous function. It can still work because it doesn't have a curve at all hence some specialization in implementation could be done to accommodate that fact. The name of the semantic function for the publisher of a instant distribution index is distributeValue.

For the purpose of this article, we will also explore the constant flow distribution curve, where publisher distribute one big flow at a constant flow rate to all its subscribers, where subscribers proportionally gets smaller flows according to their number of units. The name of the semantic function for the publisher of a constant flow distribution index is updateConstantFlowDistributionRate.

On a note of space complexity, for a publisher, the cost of storing its indexes is constant O(1). But for the subscribers, it is rather of linear O(N), for reasons this article will not elaborate more on.

Since to calculate current balance of a subscriber, it is necessary to iterate through all its subscriptions, the time complexity story is the same for subscribers.

Common variables

• t_s: settled at
• sv: settled value

Variables for publisher

• vpu: value per unit (of the index).

Variable For subscriber

• svpu: settled value per unit (of each subscriber).

How these variables are updated:

1. Publisher vpu is always updated for either a publisher operation (distributeFlow, or updateConstantFlowDistribution) or a subscriber operation (updateSubscription units).
2. Publisher's balance curve is indistinguishable between sending to 1 participant to N subscribers. This observation also leads to the design of using "lens abstraction"² when defining the specification.
3. A subscriber's svpu is updated only when a subscriber operation applied to it.

Per principle (2), balance function for publisher is the same as a simple 1 to 1 instant transfer, which is simply a constant function of a fixed value settled per principle (1).

Balance function for subscriber is:

sv + floor (u * fromIntegral (vpu - svpu))

Here is an illustrate an example case per principle (1):

First of all, the constant flow formula are provided through the lens abstraction, it is just a fancy way of saying some of the values of the formula are provided are a set of functions themselves:

-- ... (omitted noisy details)
    settledAt          :: Lens' amuLs (SFT_TS sft)
    settledValue       :: Lens' amuLs (UntappedValue (SFT_MVAL sft))
    netFlowRate        :: Lens' amuLs (SFT_MVAL sft)
-- ... (omitted noisy details)
    balanceProvided (MkMonetaryUnitData a) t =
        let b = sv + coerce (fr * fromIntegral (t - t_s))
        in  -- ... (omitted noisy details)
        -- (.^) is the lens accessor/getter function, similar to "." in OO languages.
        where t_s = a^.settledAt
              sv  = a^.settledValue
              fr  = a^.netFlowRate

What really matters above is the formula in b, and knowing that it needs three set of lenses: settledAt, settledValue and netFlowRate to be able to compute.

Per principle (2), balance function for publisher is the same as the 1 to 1 constant flow, hence its lenses are trivial:

-- ... the data record for publisher
data PublisherData sft = PublisherData
    { pub_settled_at      :: SFT_TS sft
    , pub_settled_value   :: UntappedValue (SFT_MVAL sft)
    , pub_total_flow_rate :: SFT_MVAL sft
    }
-- ... use field template to generated lenses
    settledAt    = $(field 'pub_settled_at)
    settledValue = $(field 'pub_settled_value)
    netFlowRate  = $(field 'pub_total_flow_rate)

Balance function for subscriber is a tad more complex but still succinct. It is also provided through a set of constant flow lenses:

    settledAt     = readOnlyLens
        (\(-- ... syntaticcal pattern matching noise omitted
          ) -> s_t)

    netFlowRate   = readOnlyLens
        (\(( -- ... syntaticcal pattern matching noise omitted
           ) -> if tu /= 0 then floor $ fromIntegral dcfr * u / tu else 0)

    settledValue = readOnlyLens
        (\( -- ... syntaticcal pattern matching noise omitted
          ) -> let compensatedΔ = dcfr * fromIntegral (t_dc - t_sc)
                   compensatedVpuΔ = if tu /= 0 then floor $ fromIntegral compensatedΔ / tu else 0
               in  sv + floor (u * fromIntegral (vpu - svpu - compensatedVpuΔ)))

In addition to the common variables:

• Let fpu be flow per unit, then dcfr is the distribution flow rate of the index: dcfr = fpu * total_units.
• In settledValue function, t_dc is the s_t of the publisher side, while t_sc is the s_t of the subscriber side.

The following visual example should show you how all these formulas compose together nicely.

Here is an illustrate an example case per principle (1):

It should show why compensatedVpuΔ was needed behind the lens abstraction in the "bar sticks algebra" on the bottom right side.

In computer science, non-blocking synchronization ensures that threads competing for a shared resource do not have their execution indefinitely postponed by mutual exclusion. A non-blocking algorithm is lock-free if there is guaranteed system-wide progress; wait-free if there is also guaranteed per-thread progress¹.

This simple diagram shows more clearly the idea:

    +------------------------------+--------------------------------+
    |                              |                                |
    |      Mutual Exclusion        |  Non-Blocking                  |
    |                              |                                |
    |                              |    +-------------------------+ |
    |          |     |             |    |                         | |
    |          |  H  |             |    |   Lock-Freedom          | |
    |          |  y  |             |    |                         | |
    |          |  b  |             |    |    +------------------+ | |
    | Blocking |  r  | Busy-Waiting|    |    |                  | | |
    |          |  i  |  (Polling)  |    |    |   Wait-Freedom   | | |
    |          |  d  |             |    |    |                  | | |
    |          |  s  |             |    |    +------------------+ | |
    |          |     |             |    |                         | |
    |                              |    +-------------------------+ |
    |                              |                                |
    +------------------------------+--------------------------------+

Using mutual exclusion is the most instinctive and easiest way to protect data from corruption in concurrent multi-threaded programming, which simply creates a critical region around the operations of data structure. It works fine most of the situations, but in some situations, lock is just too expensive or even not available. One example is for some ISR(Interrupt Service Routines), if it disables the interruption, then the scheduler will not be run until they open the interruption again, if it also waits for some resources which is hold by some task, then it will never available because scheduler stops. Another example is in RTOS, higher priority wait for the lower priority task to release the resource, then it causes priority-inversion. So, non-blocking algorithms are born to solve these problem without using mutual exclusions.

Valois published his most cited paper talking about lock-free data structure at 1995². But unfortunately, there are some mistakes with the memory management method introduced by Valois³.

But algorithms from Valois needs special memory management, and it's just too complicated to use. Michael and Scott published their own algorithms based on the idea of cooperative task from Valois⁴.

There's another more detailed notes on lock-free and wait-free algorithms area from Internet⁵.

Provide a non-blocking algorithm that maintains an array of fixed-size slots with the following interface:

• void InitSlots(void)

  Slots initialization.

• SLOTID GetSlot(void)

  Exclusively get an id of one free slot, and prevent other user to get this slot.

• void PutSlot(SLOTID id)

  Reclaim a slot returned by GetSlot, and make it free to get again.

• DATA* DecodeSlotID(SLOTID id)

  Decode a id of slot, and return the memory address of that slot.

Atomic operation CAS(compare-and-swap) atomically compares the contents of a memory location to a given value and, if they are the same, modifies the contents of that memory location to a given new value⁶. The following algorithm assume that CAS is available on the target hardware.

typedef struct
{
    int next;
    DATA data;
}Node;

Node Slots[MAX_SLOT_NUM];

int head;

void InitSlots(void)
{
    int i;

    for (i = 0; i < MAX_SLOT_NUM - 1; ++i)
    {
        Slots[i].next = i+1;
    }
    Slots[i].next = NULL_ID;
    head = 0;
}

int GetSlot(void)
{
    int oldhead;
    int next;

    do {
        oldhead  = head;
        if (oldhead == NULL_ID)
        {
            return NULL_ID;
        }
        else
        {
            next = Slots[oldhead].next;
        }
    } while(!CAS(&head, oldhead, next));

    return oldhead;
}

void PutSlot(int id)
{
    int oldhead;

    do {
        oldhead = head;
        Slots[id].next = oldhead;
    } while(!CAS(&head, oldhead, id));
}

DATA* DecodeSlotID(int id)
{
  return &Slots[id].data;
}

The idea of this algorithm is to use CAS to check when modify the head, if it's still the old value. This is commonly called read-modify-write. But this arises the well-known ABA problem.

The above algorithm has a subtle problem, it assumes that if the id didn't change, then the list remains the same also. But it's very common to happen that other tasks takes head and head.next and then returns the head, now the head.next actually changed. This problem is known as ABA problem⁷.

There are several ways to solve it. Valois gave a methodology of memory management which tracks use count of pointers⁸. This way assures that a pointer possessing by some one will never be allocated until no one has a copy of the pointer, thus avoiding the ABA problem to happen. Michael and Scott publishes their fixes on Valois's memory management mistakes⁹.

Another way is to use pointer tag, which adds an extra "tag" bits to the pointer. The "tag" usually increments itself on every copy operation. Because of this, the next compare-and-swap will fail, even if the addresses are the same, because the tag bits will not match. This does not completely solve the problem, as the tag bits will eventually wrap around, but helps to avoid it.

typedef union
{
    /** to write */
    uint_t Value;

    /** to write */
    struct
    {
        /** to write */
        uhalfint_t Counter;
        /** to write */
        uhalfint_t Index;
    } Data;
} SLOTID;

Type "uhalfint_t" is half length of uint_t, uint_t is unsigned integer type. The "Counter" here is the "tag" of the pointer.

Now the algorithm looks like this:

typedef struct
{
    SLOTID next;
    DATA data;
}Node;

Node Slots[MAX_SLOT_NUM];

SLOTID head;

static inline
SLOTID NewSLOTID(uhalfint_t index)
{
    SLOTID id;

    id.Data.Counter = 0;
    id.Data.Index = index;

    return id;
}

static inline
bool SLOTID_CAS(SLOTID *id, SLOTID oldid, SLOTID newid)
{
    /* Increae the counter to avoid ABA problem */
    ++newid.Data.Counter;

    return CAS(&id->Value,  oldid.Value, newid.Value);
}

void InitSlots(void)
{
    int i;

    for (i = 0; i < MAX_SLOT_NUM - 1; ++i)
    {
        Slots[i].next = NewSLOTID(i+1);
    }
    Slots[i].next = NewSLOTID(NULL_ID);
    head = NewSLOTID(0);
}

SLOTID GetSlot(void)
{
    SLOTID oldhead;
    SLOTID next;

    do {
        oldhead  = head;
        if (oldhead == NULL_ID)
        {
            return NULL_ID;
        }
        else
        {
            next = Slots[oldhead.Data.Index].next;
        }
    } while(!SLOTID_CAS(&head, oldhead, next));

    return oldhead;
}

void PutSlot(SLOTID id)
{
    SLOTID oldhead;

    do {
        oldhead = head;
        Slots[id.Data.Index].next = oldhead;
    } while(!SLOTID_CAS(&head, oldhead, id));
}

DATA* DecodeSlotID(SLOTID id)
{
  return &Slots[id.Data.Index].data;
}

The key algorithm is the SLOTID_CAS operation: every time it's going to change the SLOTID, it uses SLOTID_CAS, which increase the Counter then CAS. This makes the ABA like ABA'. The index can be the same, but the counter is unlikely the same, the wider range of Counter is, the lesser possibility ABA will happen. On a 32-bit machine, range of Counter is [0..2¹⁶].

The problem of packing counter and index into a integer is obvious: the limitation number of array elements on a 32-bit machine is 2¹⁶. And the counter limitation is 2¹⁶, after that it wraps to 0. 2¹⁶ is not a big enough value to soothe the skeptics, so on some architecture wider CAS is provided. Wider CAS is different from Multi CAS, the former can CAS on an adjacent memory fields thus be called wider, but the latter can CAS on unrelated memory fields.

On later inter x86 processor, it provides an instruction called CMPXCHG8B, which compare-and-swap-8-bytes¹⁰. By this instruction, we can operate on a normal memory pointer instead of a memory pointer, and its "tag" which has a range as large as 2³².

CAS2 is a realistic existence of Multi CAS, but only on some Motorola 680x0 processors.

In computer science, load-link (LL, also known as "load-linked" or "load and reserve") and store-conditional (SC) are a pair of instructions that together implement a lock-free atomic read-modify-write operation.

Load-link returns the current value of a memory location. A subsequent store-conditional to the same memory location will store a new value only if no updates have occurred to that location since the load-link. If any updates have occurred, the store-conditional is guaranteed to fail, even if the value read by the load-link has since been restored. As such, an LL/SC pair is stronger than a read followed by a compare-and-swap (CAS), which will not detect updates if the old value has been restored.¹¹

LL/SC can finally make skeptics happy, it doesn't just make ABA problem look like ABA', but solve it in another say. The algorithm with LL/SC can be:

typedef struct
{
    int next;
    DATA data;
}Node;

Node Slots[MAX_SLOT_NUM];

int head;

void InitSlots(void)
{
    int i;

    for (i = 0; i < MAX_SLOT_NUM - 1; ++i)
    {
        Slots[i].next = i+1;
    }
    Slots[i].next = NULL_ID;
    head = 0;
}

int GetSlot(void)
{
    int oldhead;
    int next;

    do {
        oldhead  = LL(&head);
        if (oldhead == NULL_ID)
        {
            return NULL_ID;
        }
        else
        {
            next = Slots[oldhead].next;
        }
    } while(!SC(&head, next));

    return oldhead;
}

void PutSlot(int id)
{
    int oldhead;

    do {
        oldhead = LL(&head);
        Slots[id].next = oldhead;
    } while(!SC(&head, id));
}

DATA* DecodeSlotID(int id)
{
  return &Slots[id].data;
}

To use the above algorithm, the users have to also use LL/SC to load and store the slot id because of the ABA problem. But since realistic LL/SC implementations all have limitations, actually LL/SC version algorithm is more difficult to use than the CAS version.

Real implementations of LL/SC can be found on Alpha, PowerPC¹², MIPS, ARMv6(or above). But they're all Weak LL/SC, SC can fail even if there's no update between LL and corresponding SC, for example:

• The CPU can only reserves a memory region at a time.
• A context switching between them can cause the SC fail.

The first limitation can cause a lot of ideal algorithms based on LL/SC fail. So CAS version algorithm is still preferable.

Wait-Free Fix-size Slots Management is a simple version of non-blocking memory management implementation, it only manage fix-size slots. But it already make a lot of Non-Blocking algorithm common problems and tricks emerging. Later we'll see a implementation of Wait-Free Fifo Queue based on this Slots Management.

Provide a non-blocking algorithm that provides a FIFO Queue with the following interface:

• void InitFIFO(void)

  FIFO queue initialization.

• bool Enqueue(DATA data)

  Push a data into the FIFO queue. Return TRUE if success, return FALSE only if the FIFO is full.

• bool Dequeue(DATA* pdata)

  Pull a data from the FIFO queue. Return TRUE if success, return FALSE only if the FIFO is empty.

The algorithm introduced here is based on a link-list structure¹³. It's a single link-list with head and tail pointers. It looks like:

   +-------+     +-------+     +-------+     +-------+
   |       |     |       |     |       |     |       |
   |      -+---->|      -+---->|      -+---->|      -+---->NULL
   |       |     |       |     |       |     |       |
   +---^---+     +-------+     +-------+     +---^---+
       |                                         |
       |                                         |
       |                                         |
      HEAD                                      TAIL

New data is pushed to the tail, and old data is pulled from head.

To dequeue a data, first read the HEAD value, and use CAS to swap the HEAD pointer to it's next pointer. And the old HEAD value is the data that dequeued. To avoid ABA problem¹⁴, we should use SLOTID_CAS which described in the "Fix-size Slots Management"¹⁵.

   +-------+     +-------+     +-------+     +-------+
   |       |     |       |     |       |     |       |
   |      -+---->|      -+---->|      -+---->|      -+----> NULL
   |       |     |       |     |       |     |       |
   +-------+     +---^---+     +-------+     +---^---+
                     |                           |
                     |                           |
                     |                           |
                    HEAD                        TAIL

Enqueue operation is more complicated than dequeue operation, because it has to change two state: the next pointer of the tail slot, and the tail pointer. If we have MCAS(Multi CAS) or at least Double CAS¹⁶, then the problem is easy to solve. But since DCAS is not widely available in computer system, so a so-called cooperative method is introduced firstly by Valois¹⁷.

In cooperative method, enqueue operation first allocates a new slot, and sets next pointer of tail slot to the new slot. Then set tail pointer to new slot. All theses set operation use SLOTID_CAS, so the second step can fail, if someone others enters in, and set the tail pointer. Which leaves the FIFO in a intermediate state:

   +-------+     +-------+     +-------+     +-------+
   |       |     |       |     |       |     |       |
   |      -+---->|      -+---->|      -+---->|      -+---->NULL
   |       |     |       |     |       |     |       |
   +---^---+     +-------+     +---^---+     +-------+
       |                           |
       |                           |
       |                           |
      HEAD                        TAIL

To complete the intermediate state:

1. The next enqueue operation should try to move the TAIL forward, until the TAIL at the end, the enqueue operation should not change the TAIL slot next pointer.
2. The next dequeue operation should also try to move the TAIL forward when the head meets the tail pointer.

This algorithm uses CAS version of "Fix-size Slots Management"¹⁵.

typedef struct
{
    DATA data;
    SLOTID next;
} Node;

SLOTID head;
SLOTID tail;

void InitFIFO(void)
{
    Node *sentinel;

    /* This algorithm relies on the fix-size slots management */
    InitSlots();

    /* Sentinel slots */
    head = tail = GetSlot();
    sentinel = DecodeSlotID(head);
    sentinel->next = NULL_ID;
}

/*
  Origin Algorithm:
  E01: node = new node()
  E02: node->value = value
  E03: node->next.ptr = NULL
  E04: loop
  E05:   tail = Q->Tail
  E06:   next = tail.ptr->next
  E07:   if tail == Q->Tail
  E08:     if next.ptr == NULL
  E09:       if CAS(&tail.ptr->next, next, <node, next.count+1>)
  E10:         break
  E11:       endif
  E12:     else
  E13:       CAS(&Q->Tail, tail, <next.ptr, tail.count+1>)
  E14:     endif
  E15:   endif
  E16: endloop
  E17: CAS(&Q->Tail, tail, <node, tail.count+1>)
*/
bool Enqueue(DATA data)
{
    SLOTID newid;
    Node *newnode;
    SLOTID oldtail;
    Node *oldtailnode;
    SLOTID nextid;
    Node *nextnode;

    /* E01 */
    newid = GetSlot();
    newnode = DecodeSlotID(newid);
    if (newnode == NULL) return FALSE;
    /* E02 */
    newnode->data = data;
    /* E03 */
    newnode->next = NULL_ID;
    /* E04 */
    do {
        /* E05 */
        oldtail = tail;
        oldtailnode = DecodeSlotID(oldtail);
        /* E06 */
        nextid = oldtailnode->next;
        nextnode = DecodeSlotID(nextid);
        /* E07 */
        if (oldtail == tail)
        {
            /* E08 */
            if (nextnode == NULL)
            {
                /* E09 */
                if (SLOTID_CAS(&oldtailnode->next, next, newid))
                {
                    /* E10 */
                    break;
                /* E11 */
                }
            }
            /* E12 */
            else
            {
                /* E13 */
                SLOTID_CAS(&tail, oldtail, next);
            /* E14 */
            }
        /* E15 */
        }
    /* E16 */
    } while(1);
    /* E17 */
    SLOTID_CAS(&tail, oldtail, newid);

    return TRUE;
}

/*
  Origin Algorithm:
  D01:  loop
  D02:    head = Q->Head
  D03:    tail = Q->Tail
  D04:    next = head->next
  D05:    if head == Q->Head
  D06:      if head.ptr == tail.ptr
  D07:        if next.ptr == NULL
  D08:          return FALSE
  D09:        endif
  D10:        CAS(&Q->Tail, tail, <next.ptr, tail.count+1>)
  D11:      else
  D12:        *pvalue = next.ptr->value
  D13:        if CAS(&Q->Head, head, <next.ptr, head.count+1>)
  D14:          break
  D15:        endif
  D16:      endif
  D17:    endif
  D18:  endloop
  D19:  free(head.ptr)
  D20:  return TRUE
*/
bool Dequeue(DATA *pdata)
{
    SLOTID oldhead
    Node *oldheadnode;
    SLOTID oldtail;
    Node *oldtailnode;
    SLOTID next;
    Node *nextnode;

    /* D01 */
    do {
        /* D02 */
        oldhead = head;
        oldheadnode = DecodeSlotID(oldhead);
        /* D03 */
        oldtail = tail;
        oldtailnode = DecodeSlotID(oldtail);
        /* D04 */
        next = oldhead->next;
        nextnode = DecodeSlotID(next);
        /* D05 */
        if (oldhead == head)
        {
            /* D06 */
            if (headnode == tailnode)
            {
                /* D07 */
                if (nextnode == NULL)
                {
                    /* D08 */
                    return FALSE;
                /* D09 */
                }
                /* D10 */
                SLOTID_CAS(&tail, oldtail, next);
            }
            /* D11 */
            else
            {
                /* D12 */
                *pdata = nextnode->data;
                /* D13 */
                if (SLOTID_CAS(&head, oldhead, next)
                {
                    /* D14 */
                    break;
                /* D15 */
                }
            /* *D16 /
            }
        /* D17 */
        }
    /* D18 */
    }
    /* D19 */
    PutSlot(oldhead);
    /* D20 */
    return TRUE;
}

In enqueue, E13 is the cooperative operation.

In dequeue, D10 is the cooperative operation.

Valois also introduced a array based Non-Blocking FIFO algorithm¹⁸, but it's not feasible on real machine because it requires CAS on unaligned memory region.

This article introduces a link-listed based Non-Blocking algorithm for FIFO queue. It's based on the "Fix-size Slots Management"[2], and feasible on the platforms that support CAS.

#!/bin/sh

trap exit USR1

timeout(){
    echo timeout
    kill -USR1 $1
}

start_timer HANDLER $(( 5 * 1000 * 1000 )) timeout $$
echo -n "READ : "
read F
kill_timer HANDLER
echo "GOT : "$F

Notice

trap TERM HUP QUIT yourself, since if you terminated the process before got any input, timeout event handler will not terminated automatically. You can call kill_timer in you trap handler.

• LINK_NODE

  A link node has these data fields:

  {
    DATA                 data;
    SHPOINTER<LINK_NODE> next_node;
  }

• FIFO_STATE

  FIFO_STATE is a type of GAO Object that atomically maintains a data structure with these data fields:

  {
    SHPOINTER<LINK_NODE> header;
    SHPOINTER<LINK_NODE> tail;
    LINK_NODE            new_node;
  }

kgdb 选项 ：

• CONFIG_KGDB=y
• CONFIG_{KGDBSERIALCONSOLE}=y

选项在 Kernel hacking 里可以找到 同时，为了能在系统运行时中断系统并出发远程 gdb，必须打开内核 Magic Sys-Rq 键选项 ：

• CONFIG_MAGICSYSRQ=y

打开内核符号调试：

• CONFIG_DEBUGINFO=y

注意事项：

• CONFIG_DEBUGRODATA 必须被禁用，否则kgdb讲无法正常使用。

qemu ${QEMU_ARGS} \
    -kernel "$VMLINUZ" \
    -append "${KERNEL_CMDLINE} kgdboc=ttyS0,115200 kgdbwait" \
    -serial tcp::${KGDB_TCPPORT},server \
    -hda "${QEMU_HDA}" >/dev/null &

qemu 选项中：

• -kernel 编译好的内核，压缩过的
• -append 传给 kernel 的命令行选项
• -serial 使系统的第一个串口与本地的 TCP 端口关联起来，用于模拟终端，这样gdb就可以连接到目标系统而不用串口线了。
• -hda 用于运行开发系统的Linux系统qemu硬盘。你也可以在用 nfs root 启动系统，但qemu必须要求你指定至少一个qemu硬盘，你可以使

用空的硬盘，用qemu-img工具创建。

kernel 选项中：

kgdboc 的意思是 kgdb over console，这里将kgdb连接的console设置为ttyS0，波特率为115200 kgdbwait 使 kernel 在启动过程中等 待 gdb 的连接。

qemu 启动后会等待 gdb 连接 tcp 端口以启动模拟串口。

运行下面的命令启动gdb，如果没设置KGDB_GDB变量，默认用 gdbtui 启动，其中 VMLINUX 是未压缩的 kernel 文件。

${KGDB_GDB:-gdbtui} $VMLINUX

设置波特率

(gdb) set remotebaud 115200

连接目标

(gdb) target remote tcp:localhost:${KGDB_TCPPORT}

连接成功后由于启动了 kgdbwait 选项，kgdb 会在内核启动的某个阶段得到控制权：

Remote debugging using tcp:localhost:4555
kgdb_register_io_module (new_kgdb_io_ops=<value optimized out>)
    at /data/home/hellwolf/mydoc/prog/linux/linux-2.6/kernel/kgdb.c:1674
(gdb)

现在就可以开始使用 kgdb 调试内核了。

如果 gdb 遇到问题无法相应了，可以在测试系统上运行下列命令中断调试：

echo -e "\003" > /dev/ttyS1

如果你重启系统了，gdb 也需要重新连接系统。

为了在测试系统运行的时候让 gdb 获得控制权，需要使用 Sys-Rq。关于 Sys-Rq 的详细设置方法，见 Documentation/sysrq.txt。 你 可以在系统运行时键盘上输入 Sys Rq+g，然后 gdb 就会出现：

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread -1]
sysrq_handle_gdb (key=103, tty=0xc7869800)
    at /data/home/hellwolf/mydoc/prog/linux/linux-2.6/kernel/kgdb.c:1674
(gdb)

如果你不知道如何在键盘上输入，或者你需要程序控制，则可以用下列等价命令模拟：

# echo g > /proc/sysrq-trigger

(gdb) c

即可

这些都和调试普通程序一样，比如：

(gdb) b	sys_open
Breakpoint 1 at 0xc046d268: file /data/home/hellwolf/mydoc/prog/linux/linux-2.6/
fs/open.c, line 1107.
(gdb) c
Continuing.
[New Thread 612]
[Switching to Thread 612]

Breakpoint 1, sys_open (filename=0xb7f68a9c "/etc/ld.so.cache", flags=0,
    mode=0) at /data/home/hellwolf/mydoc/prog/linux/linux-2.6/fs/open.c:1107
(gdb) p filename
$1 = 0xb7f68a9c "/etc/ld.so.cache"
(gdb)n
(gdb)bt
#0  sys_open (filename=0xb7f68a9c "/etc/ld.so.cache", flags=0, mode=0)
    at /data/home/hellwolf/mydoc/prog/linux/linux-2.6/fs/open.c:1113
#1  0xc0403976 in system_call ()
    at /data/home/hellwolf/mydoc/prog/linux/linux-2.6/arch/x86/kernel/entry_32.S
:377
#2  0x00000000 in ?? ()

kgdb 不支持 tracepoints 和 watchpoints，除非有硬件调试器支持。

kgdb 的 threads 也无法正常使用。

gdb 可以定义 sequences 脚本, 功能局限，但是可以用来简化一些工作。比如在 gdb 调试状态下 lsmod 的脚本：

set $_lsmod_modules = modules->next
#       1        10   15
printf "Module          Size\n"
while $_lsmod_modules != &modules
	set $_lsmod_module = (struct module*)((unsigned char*)$_lsmod_modules-(unsigned int)&(((struct module*)0)->list))
	printf "%-15s %d\n", $_lsmod_module->name, $_lsmod_module->init_size + $_lsmod_module->core_size
	set $_lsmod_modules = $_lsmod_modules->next
end

用 source 命令可以读入外部的 gdb 命令序列文件。

gdb 脚本最大的局限性在于，没有内置的字符串比较功能，比如我要得到一个(struct module*)，我必须遍历模块列表然后做字符串匹配。 这里我用了一个比较特殊的解决办法，我定义了两个gdb sequences :

define xsrun
	if $argc == 0
		printf "Usage : xsrun xsourcecmd args...\n"
	else
		shell rm -f /tmp/*.xsource
		shell echo 0 > /tmp/seq.xsource
		if $argc == 1
			xsource '$arg0'
		end
		if $argc == 2
			xsource '$arg0' '$arg1'
		end
		if $argc == 3
			xsource '$arg0' '$arg1' '$arg2'
		end
		if $argc == 4
			xsource '$arg0' '$arg1' '$arg2' '$arg3'
		end
		if $argc == 5
			xsource '$arg0' '$arg1' '$arg2' '$arg3' '$arg4'
		end
		if $argc == 6
			xsource '$arg0' '$arg1' '$arg2' '$arg3' '$arg4' '$arg5'
		end
		if $argc == 7
			xsource '$arg0' '$arg1' '$arg2' '$arg3' '$arg4' '$arg5' '$arg6'
		end
		if $argc == 8
			xsource '$arg0' '$arg1' '$arg2' '$arg3' '$arg4' '$arg5' '$arg6' '$arg7'
		end
		if $argc == 9
			xsource '$arg0' '$arg1' '$arg2' '$arg3' '$arg4' '$arg5' '$arg6' '$arg7' '$arg8'
		end
		if $argc == 10
			xsource '$arg0' '$arg1' '$arg2' '$arg3' '$arg4' '$arg5' '$arg6' '$arg7' '$arg8' '$arg9'
		end
	end
end

define xsource
	if $argc == 1
		shell $TOOLSDIR/kgdb-xsource '$arg0'
	end
	if $argc == 2
		shell $TOOLSDIR/kgdb-xsource '$arg0' '$arg1'
	end
	if $argc == 3
		shell $TOOLSDIR/kgdb-xsource '$arg0' '$arg1' '$arg2'
	end
	if $argc == 4
		shell $TOOLSDIR/kgdb-xsource '$arg0' '$arg1' '$arg2' '$arg3'
	end
	if $argc == 5
		shell $TOOLSDIR/kgdb-xsource '$arg0' '$arg1' '$arg2' '$arg3' '$arg4'
	end
	if $argc == 6
		shell $TOOLSDIR/kgdb-xsource '$arg0' '$arg1' '$arg2' '$arg3' '$arg4' '$arg5'
	end
	if $argc == 7
		shell $TOOLSDIR/kgdb-xsource '$arg0' '$arg1' '$arg2' '$arg3' '$arg4' '$arg5' '$arg6'
	end
	if $argc == 8
		shell $TOOLSDIR/kgdb-xsource '$arg0' '$arg1' '$arg2' '$arg3' '$arg4' '$arg5' '$arg6' '$arg7'
	end
	if $argc == 9
		shell $TOOLSDIR/kgdb-xsource '$arg0' '$arg1' '$arg2' '$arg3' '$arg4' '$arg5' '$arg6' '$arg7' '$arg8'
	end
	if $argc == 10
		shell $TOOLSDIR/kgdb-xsource '$arg0' '$arg1' '$arg2' '$arg3' '$arg4' '$arg5' '$arg6' '$arg7' '$arg8' '$arg9'
	end

	if $argc > 0
		source /tmp/current.xsource
	end
end

其中 $TOOLSDIR/kgdb-xsource 是我自定义的一个寻找名字为 '$arg0' 的 xsource 脚本的工具，我的实现就是在某个目录下找名字为 $arg0 的文件：

$ cat tools/kgdb-xsource
#!/bin/bash
. $(dirname "$0")/common.sh

if [ "$#" == 0 ];then
	echo "kgdb-xsource xsourcecmd args...\\n\"" > /tmp/current.xsource
else
	XSOURCECMD=$1
	shift
	XSOURCESEQ=$(cat /tmp/seq.xsource)
	XSOURCESEQ=$((${XSOURCESEQ}+1))
	echo ${XSOURCESEQ} > /tmp/seq.xsource
	XSOURCEOFILE=/tmp/${XSOURCESEQ}-${XSOURCECMD}.xsource
	if [ -f "$XSOURCEDIR/$XSOURCECMD" ] && [ -x "$XSOURCEDIR/$XSOURCECMD" ];then
		$XSOURCEDIR/$XSOURCECMD "$@" > ${XSOURCEOFILE}
		rm -f /tmp/current.xsource
		ln -s ${XSOURCEOFILE} /tmp/current.xsource
	else
		echo "printf \"No such xsource command : $XSOURCECMD\\n\"" > /tmp/current.xsource
	fi
fi

这些脚本的目的就是，通过外部脚本生成 gdb 脚本，然后再让 gdb 执行。他首先寻找 xsource 脚本，然后运行它，得到的输出（gdb sequences)保存到 /tmp 下的某个文件中，并链接为 /tmp/current.xsource, 然后让 gdb 执行改文件。

比如 strcmp_vs 脚本，这个脚本就是为了比较内部变量和一个字符串的：

$ cat tools/xsource.d/strcmp_vs
#!/usr/bin/perl
if (@ARGV != 3) {
    print "printf \"Usage : strcmp result var str\\n\"";
    exit 1
}

($result, $var, $str) = @ARGV;
print 'if ';
$i = 0;
for (0..length($str)-1) {
    $i = $_;
    $c = substr($str, $i, 1);
    print ' && ' if $i;
    print "${var}[$i] == '$c'";
}
++$i;
print " && ${var}[$i] == '\\0'
    set \$$result = 0
else
    set \$$result = -1
end
";

利用这个基本命令，我们现在就可以实现 getmod 功能拉：

$ cat tools/xsource.d/getmod
#!/bin/sh
[ $# != 2 ] && echo "printf \"Usage : getmod modvar modname\n\"" && exit 1

MODVAR=$1
MODNAME=$2
cat <<EOF
set \$_getmod_modules = modules->next
set \$_getmod_modfound = 0
while \$_getmod_modules != &modules
	set \$_getmod_module = (struct module*)((unsigned char*)\$_getmod_modules-(unsigned int)&(((struct module*)0)->list))
	xsource strcmp_vs _getmod_modfound \$_getmod_module->name $MODNAME
	if \$_getmod_modfound == 0
		set \$$MODVAR = \$_getmod_module
		set \$_getmod_modfound = 1
		loop_break
	end
	set \$_getmod_modules = \$_getmod_modules->next
end

if \$_getmod_modfound != 1
	printf "Module \\"$MODNAME\\" cannot be found\\n"
	set \$$MODVAR = 0
end
EOF
[/code]
运行范例：
[code]
(gdb) xsource getmod modvar hello
(gdb) print $modvar->sect_attrs->attrs[0]->name
$9 = 0xc7855b40 ".note.gnu.build-id"