Using Channels to effect asynchronous threads

[rp181]

Ya, having mismatched inputs and outputs does not crash the program, but only deadlocks the involved threads. Ever other thread will continue to functional normally. Of course, this can make debugging more difficult ;)

Also, something that caused me a lot of problem when I started using channels was to not only make sure that inputs are matched by ouputs, but the data types also have to match. If I am sending an 8 bit char, I need to receive an 8 bit char, and not try and read it into a 32 bit integer.

[Obtuse]

Good point.

Makes sense, and I will no doubt run into that in the future.

[Obtuse]

A little play program for channel blocking/thread deadlocking.
(For XS1-L2, It builds and runs without error.)

Boss waits for Worker to change states 5 times before displaying a change on his port. Of course he blames the slow production on the Worker.

By adding a delay to the Boss routine the Worker would have to wait until the Boss got around to answering his send signal before getting any more work done. Lazy worker.

P.S. This does not display a waveform in my Linux 32bit XDE.
I only get the first transition on one thread. Any hints welcome.

Code: Select all

/*
 * boss.c
 * XS1-L2 chip
 */

#include <xs1.h>
#include <platform.h>
#define DELAY 21000000

on stdcore [0] : port out pzero = XS1_PORT_1K;
on stdcore [1] : port out pone = XS1_PORT_1E;

void worker (chanend ch, out port p, int delay);
void boss (chanend ch, out port q, int delay);

int main (void) {
		chan ch;
  par {		on stdcore [0] : worker ( ch, pzero, (DELAY));
			on stdcore [1] : boss ( ch, pone, DELAY*5);
  	  }
  return 0;
}
// Core 1
void boss (chanend ch, out port pone, int delay){
	unsigned bdata;

	while (1){
		ch :> bdata; //Block until worker sends.
		ch :> bdata; //block until worker sends more.
		ch :> bdata; //ditto
		// add delay counter/loop here.
		ch :> bdata; //ditto
		ch :> bdata; //ditto
		pone <: bdata;//put last sent worker data on port.
	}
}

// Core 0
void worker (chanend ch, out port pzero, int delay) {

  timer tmr;
  unsigned wt;
  unsigned wdata;

  while (1) {
    wdata = 1;
	pzero <: wdata;
    tmr :> wt;
    tmr when timerafter (wt+ delay ) :> void;
    ch <: wdata; // send 1 to boss

    wdata = 0;
    pzero <: wdata;
    tmr :> wt;
    tmr when timerafter (wt+ delay ) :> void;
    ch <: wdata; // send 0 to boss

  }
}

[lilltroll]

What happens if you change DELAY to 100 instead and run the first 10000 - 50000 cycles, so you do not need to simulate so many XMOS-CPU cycles.
The simulation has to end sometime, othervise your PC would run out of memory, and you have a large delay in your example. Have you checked the absolute time in your simulation. Does it cover several seconds ?

[Obtuse]

What happens if you change DELAY to 100 ..........
.......... Does it cover several seconds ?

That did the trick.

After stopping the simulation the Memory Used meter on the lower left of the XDE was only showing 3-4% and I thought it should be able to run for a longer period. Something new every day.

Thanks for the tip.