Concurrent Programming?

Module level state?

Variables defined outside of a function/class/actor (termed module level state) are copied in a special manner when it comes to usage within isolates. The rule is that state defined within the module spawning the isolate will be copied, but module level state defined in modules other than that spawning the isolate will be reinitialized (which means running all of the associated top level code to initialize them) within the isolate - i.e. the current state not copied.

For example:

//code defined in com.mycompany.library:
def initFromLit(){
  System out println 'initlaize fromLib'
  100
}
fromLib = initFromLit()

//code in seperate module defined in: com.mycompany.myApplication:
m = 100

com.mycompany.library.fromLib = 101
m = 101

res = { "fromLib={com.mycompany.library.fromLib}, m={m}" } !

//com.mycompany.library.fromLib == 101
//res == "fromLib=100, m=101":

Above we see that fromLib has 'reverted' to it's initial state of 100, whereas m is captured as 101. Furthermore, initFromLit() will be executed twice (once on the initial use of fromLib and secondly on the copying into the spawned isolate) - so 'initlaize fromLib' will be output to the console twice.

Default exception handler?

In cases where an isolate does not return a value from a ref the default exception handler shall handle it. This simply prints a stack trace to the console via System.err and permits execution of the program to otherwise continue uninterrupted.

def divOp(a int, b int) => a/b//can throw a div by zero, ArithmeticException

divOp(12, 0)! //no return value assignment!
//any thrown ArithmeticException will be printted to the console via System.err

Dedicated Thread?

The concurrent.DedicatedThread() executor will force execution of the isolate to take place within a dedicated worker with its own thread. This is particularly useful in cases where one is calling non-Concurnas JVM code (for instance, written in Scala or Java) which blocks on io (e.g. networking) or otherwise (e.g. infinite loops). Recall that blocking code would otherwise prevent other isolates from being executed in a timely manner via the usual mechanism, so this executor is a good choice in this instance.

If the called code within the isolate either directly or indirectly spawns new isolates, then these will be multiplexed as normal onto the root set of workers.

This executor should be used judiciously since creating dedicated threads doesn't scale as well as isolates multiplexed onto the usual set of shared workers. Though if one is calling code which is known to block, then this is usually the only, and best, option available.

Here is an example:

added = {10+10}!(concurrent.DedicatedThread())

It is not necessary to explicitly terminate a concurrent.DedicatedThread() executor since it is meant for once time use, it is automatically terminated after completion of an isolate executed via it. Note that this means that concurrent.DedicatedThread() executors cannot be reused.

Dedicated Thread Worker Pool?

The concurrent.DedicatedThreadWorkerPool() executor creates a pool of workers on to which isolates may be executed via reference to the executor instance. It is similar to the aforementioned concurrent.DedicatedThread() executor in that it will force execution of the isolate to take place within a dedicated worker with its own thread. The difference here is that if the called code within the isolate either directly or indirectly spawns new isolates, then these will be multiplexed onto the new pool of dedicated workers.

The number of workers created is definable by specifying the workerCount default parameter of the concurrent.DedicatedThreadWorkerPool() executor constructor. If unspecified this value defaults to the number of core Concurnas workers spawned by the scheduler associated with the current running isolate in which the concurrent.DedicatedThread() executor is created.

Unlike the concurrent.DedicatedThread() executor, it is best practice to explicitly terminate the executor after one has finished using it as this will shut down the spawned worker threads which are no longer useful. This can be achieved by calling the terminate method on the executor. Note that, upon garbage collection, or termination of an implicit 'parent' executor (including the root executor), the worker pool will be implicitly terminated.

An example of usage:

pool = new concurrent.DedicatedThreadWorkerPool()
added = {10+10}!(pool)
pool.terminate()

Returning values from sync?

Sync blocks may return a value:

def gcd(x int, y int){//greatest common divisor of two integers
  while(y){
    x, y = y, x mod y
  }
  x
}

calc1 int:
calc2 int:

complete = sync{
  calc1 = {gcd(8, 20)}!
  calc2 = {gcd(6, 45)}!
  "all done"
}

//complete == "all done" and calc1 and calc2 have now been set

Creating refs?

There are a number of ways in which refs can be created:

aref1 int: //defined but unassigned local ref of type int
aref2 = new int://defined but unassigned local ref of type int
aref3 int := 21 //defined and assigned local ref of type int
aref4 := 21 //assigned local ref of inferred type int
aref5 = 21: //assigned variable of inferred type int: with the right hand side being a ref creation expression
aref6 = {21}! //assigned variable of inferred type int: - right hand side being a ref returned from an isolate - this is the most computationally expensive variety of ref creation - if you find yourself doing this to create simple refs from expressions that don't require concurrent execution, consider using the preceding form

Refs can be created of any type - even refs themselves (see below refs of refs)! Refs may not be of nullable types.

All the refs above are of type int:. As can be seen above the key when creating refs is the use of : postfixed to a type or prefixed to the assignment operator = - this tells the compiler that we wish to create a ref type.

Using refs?

Just like normal variables, we can assign a value to the ref at any point during or post declaration. For example:

aref1 int: //defined but unassigned local ref of type int
aref1 = 100 //assigned just like normal!

When we have a method or other location where a ref is expected as an input type, and the input we have provided is of that refs component type, Concurnas will automatically create a ref to hold that value and set it as appropriate. For example:

def expectsRef(a int:) int => a:get()

expectsRef(12)//12 is automatically converted into a ref, i.e. expectsRef(12:)

a int:

{a = 99}!//execute our ref assignment in a separate isolate

b int = a//a is unassigned when our isolate spawned above complete's execution

def takesInt(a int) => a

res = {a = 99}!

takesInt(res)//res is dereferenced

a int: = 12
b = a:
c := a

//the &== operator tests for equality by object reference and not by object value as the == operator does
assert b: &== a: //a and b are references to the same ref
assert c: &== a: //a and c are references to the same ref

aref = 12:
aref:setException(new Exception("uh oh"))

hase = aref:hasException() //returns true, an exception has beenset

Notable methods on refs?

All refs are subtypes of the class: com.concurnas.bootstrap.runtime.ref.Ref. This class exposes a number of occasionally useful methods of note that are accessible via the : operator:

• def isSet() boolean - returns true if a ref has been closed, an initial value or an exception set (non blocking method).

• def waitUntilSet() void - returns when a ref has been closed, an initial value or an exception set (blocking method).

• def close() void - close a ref, no further values may be assigned.

• def isClosed() boolean - returns true if a ref has been closed (non blocking method).

• def setException(e Throwable) boolean - set an exception on a ref.

• def hasException() boolean - returns true if a ref has been closed (non blocking method).

When creating a ref via the aforementioned methods one is creating a ref of type: com.concurnas.runtime.ref.Local<X> where X is the reified type of the ref. In other words:

aref1 int:
//is equvilent to:
bref1 com.concurnas.runtime.ref.Local<int>

Instances of Local<X> provide the following additional methods:

• set(x X) void - set the latest value of the ref. (equivalent to assignment)

• get() X - get the latest value of the ref. (blocking method).

• getNoWait() X? - get the latest value of the ref. Value will be returned as null if no initial value has been set (non blocking method).

• get(withNoWait boolean) X? - get the latest value of the ref. May return null. (optionally blocking method).

Arrays of refs?

Arrays of refs may be created in the usual manner:

arrayofrefs1 = [1: 2: 3:]
arrayofrefs2 = new Integer:[10]
arrayofrefs3 = new Integer:[2, 2](1)//with array initalizer

Arrays of refs are of type: com.concurnas.runtime.ref.LocalArray<X> where X is the ref type (Integer: above).

Ref variable reassignment?

The ref variables themselves may be reassigned by ensuring that the assignment operator is prefixed with :, for example:

aref int: = 100
bref int: = 200
assert aref <> bref  //values not equal
assert aref: <> bref://refs not equal

aref = bref //assign the value of bref to aref
assert aref == bref  //values equal!
assert aref: <> bref://refs not equal


aref := bref //assign the ref itself: bref to aref
assert aref == bref  //values equal!
assert aref: == bref://refs equal!

Refs are reified types?

refs are reified types hence Concurnas knows what type a ref is holding at runtime. This allows us to safely write code such as the following:

def checkIfIntRef(something Object) boolean => something is int:

Closing refs?

refs can be put into a closed state, after which no further values may be assigned to them, and any reactive components which use them will no longer consider them to be something to watch for changes to react to after notification.

aref = 10:
aref:close()
assert aref:isClosed()//aref is now closed

Any reactive components that are registered to watch for changes to a ref will be invoked upon said ref being closed, for example:

aref := 10

isclosed boolean:
onchange(aref){
  if(aref:isClosed()){
    isclosed = true
  }
}
aref:close()

await(isclosed)

Above, we create a ref isclosed which is only set by our onchange block after aref has been closed.

Custom refs?

In 99% of situations the built in ref types are all we need to solve problems. But sometimes it can be useful to define our own custom refs (e.g the gpus.GPURef ref type). To do this all we need to is subclass the com.concurnas.runtime.ref.Local class. However, there are a few caveats to be remembered when building custom refs which we shall explore here.

Refs, being reified types, require an additional initial argument, of type Class<?>[], be added to all defined constructors to hold the reified type information generated seamlessly by Concurnas at compilation time. When constructing refs this extra argument does not need to be populated. For example:

class CustomRef<X>(type Class<?>[], ~extraArg int) < com.concurnas.runtime.ref.Local<X>(type){
  this(type Class<?>[]) => this(type, 99)
}

class CustomRef<X>(type Class<?>[], ~event int) < com.concurnas.runtime.ref.Local<X>(type)
class CustomRefWithNoArg<X>(type Class<?>[], ~event int) < com.concurnas.runtime.ref.Local<X>(type){
  this(type Class<?>[]) => this(type, 12)
}

def fail(a Object) Object:CustomRef{
  return null//implicitly create a CustomRef to hold null - which will fail
}
def ok(a Object) Object:CustomRefWithNoArg {
  return null//implicitly create a CustomRefWithNoArg
}

ok("123")//this will return a Object:CustomRefWithNoArg object
fail("123")//this will throw a runtime exception because there is no no argument constructor defined for CustomRef

class CustomRef<X>(type Class<?>[], ~extraArg int) < com.concurnas.runtime.ref.Local<X>(type){
  this(type Class<?>[]) => this(type, 99)
}

inst1 = int:CustomRef(12)//insatnce of our CustomRef
inst2 = int:CustomRef()//insatnce of our CustomRef

inst1 int:CustomRef = 12//insatnce of our CustomRef with implicit contruction

//above is equivilent to:
inst2 int:CustomRef; inst2 = 12

inst1 int:CustomRef; 
inst1 = 12

import com.concurnas.runtime.ref.RefArray 

xx int:RefArray = [Integer(1) 2 3 4]
xx[0] := 99
elm = xx[3]
	
//xx == [99 2 3 4]
//elm == 4

Nested refs?

The Concurnas ref syntax supports nesting, i.e. refs of refs. Though this feature is of limited usability there are occasions where it can be incredibly useful. The principles are straightforward. Let's look at some examples:

aref1 int:: //declare a ref of a ref
aref2 int:: = 53 //declare and assign a value to the ref of a ref
aref3 = 53:: //infer type as ref of ref: int::

anint1 int = aref2 //extract value helf by ref of ref
anint2 int = aref2::get() //extract value helf by ref of ref
nestedref int: = aref2:get()//extract ref held by ref

Above we can see that when we declare nested refs we need only append the ref operator to the element we are nesting. In the case of a type this is: int:: and when calling methods on nested refs: aref2:get(). Concurnas will automatically ref/unref a value to the appropriate level of nesting in cases where possible:

def expectsRefOfRef(arefofref int::) => arefofref

aref1 = 12:
expectsRefOfRef(aref1)//equvilent to: aref1: (which is of type int::)

Refs of custom refs, and vice verse may be created and used in a similar manner:

class CustomRef<X>(type Class<?>[], ~extraArg int) < com.concurnas.runtime.ref.Local<X>(type)

custRefOfRef int::CustomRef = 16//CustomRef holding a ref of type int

await?

The await keyword takes a series of expressions evaluating to one or more references and will block execution until at least one of those references has been set. For example:

complete boolean:
{
  //some complex calculation..
  complete = true
}!//spawn an isolate to execute the above concurrently.

await(complete)//pause further execution until complete is set

execount int: = 0
for(a in 1 to 10){
  //some complex calculation..
  execount++
}!//spawn an isolate to execute the above concurrently.

await(execount; execount==10)//pause further execution until execount == 10

every and onchange?

Concurnas provides two reactive blocks which are central to most reactive programs. These are the every and onchange blocks. They both take a ref (or group of refs) and will monitor this ref(s) for changes. Upon a notification of a change occuring the body of the block shall be executed.

Like the await statement, every and onchange blocks persist within their own isolate, when they react to changes to refs they execute their code body within that isolate. Hence upon their successful initialization they immediately return the flow control to the invoking isolate.

The difference between the every and onchange blocks is that the every block will be initially triggered upon initialization of the block if any of the monitored refs has an initial value set. The onchange block on the other and will only be triggered if a change is made to a ref post initialization.

Here is an example of a every and onchange block:

lhs int:
rhs int:
result1 int:
result2 int:
every(lhs, rhs){}
  result = lhs + rhs
}

onchange(lhs, rhs){}
  result2 = lhs + rhs
}

every and onchange, just like all blocks in Concurnas, supports the single line block syntax, i.e.:

lhs int:
rhs int:
result1 int:
every(lhs, rhs){}
  result1 = lhs + rhs
}
//can be written as:
plusop2 = every(lhs, rhs) {lhs + rhs}

every and onchange blocks will be triggered every time a change is made to a monitored ref. Code executed within their body which references the ref(s) that were changed in the transaction which caused that trigger with have their values locked at the value which was written in the transaction, other refs (which may or may not be monitored) will reflect the latest state of the ref in question as normal. An example:

aref int:
onchange(aref){
  System.out.println("latest value of aref: {aref:get()}")
}

aref=1
aref=2
aref=3

//will output to System.out:
//1
//2
//3

every and onchange blocks will cease to monitor refs or be executable (and hence become eligible for garbage collection) when all of their monitored refs are in a closed state or are otherwise out of scope. Additionally if the block is explicitly returned from via the return keyword, then it will also cease to be executable - see the Returning from \lstinline!every! and \lstinline!onchange! section for more details.

def retRef() int: => 12
itmchanged = onchange(watch = retRef()) { watch }

lhs int:
rhs int:
plusop2 = every(lhs, rhs){lhs + rhs}

lhs int:
rhs int:
howmanyclosed = every(lhs, rhs; onlyclose){changed.getChanged().length}

x := 10
y := 5

result = onchange { x + y } //x and y will automatically be monitored for changes

x := 10
def xSquared() => x ** 2

result = onchange{ xSquared()}//x will NOT be automatically monitored

Compact every and onchange?

Concurnas provides a more compact way to define onchange and every blocks when they are used on the right hand side of an assignment. In essence, one can replace onchange with <- and every with <=.

x := 10
y := 5

res1 <-(x, y) x + y //onchange with dependencies explicitly defined
res2 <=(x, y) x + y //every with dependencies explicitly defined

res3 <- x + y //onchange with dependencies implicitly defined
res4 <= x + y //every with dependencies implicitly defined

This compact syntax in particular makes performing reactive computing with refs very convenient.

Async?

The async block enables us to define a collection of related every and onchange blocks with an optional pre and post block. async blocks perform execution within one dedicated isolate for all every and onchange blocks. Like every and onchange blocks, async blocks will permit the initializing isolate to continue with execution post initialization.

The optional pre block enables us to define and initialize state which is accessible only to the every and onchange blocks of the async block. The optional post block enables us to execute code when the monitored refs of all the every and onchange blocks are in a closed state and the async block terminated.

Example:

finalCount int:
tally1 = 2:
tally2 = 2:

async{
  pre{
    count = 0
  }
	
  every(tally1){
    count += tally1	
  }		
	
  onchange(tally2){
    count += tally2		
  }
	
  post{
    finalCount = count
  }
}

tally1 = 9; tally1 = 10; tally1 = 10
tally2 = 45; tally2 = 3; tally2 = 53

tally1:close(); tally2:close()

await(finalCount)

//finalCount == 132

finalCount int:
tally1 = 2:
tally2 = 2:

lastproc = async{
  pre{
    count = 0
  }

  every(tally1){
    count += tally1
    count//return this value
  }		

  onchange(tally2){
    count += tally2		
    count//return this value
  }

  post{
    finalCount = count
  }
}

tally1 = 9; tally1 = 10; tally1 = 10
tally2 = 45; tally2 = 3; tally2 = 53

tally1:close(); tally2:close()

await(finalCount)

//finalCount == 132

tally1 = 2:
tally2 = 2:

finalCount = async{
  pre{
    count = 0
  }

  every(tally1){
    count += tally1
  }		

  onchange(tally2){
    count += tally2		
  }

  post{
    count//return this value
  }
}

tally1 = 9; tally1 = 10; tally1 = 10
tally2 = 45; tally2 = 3; tally2 = 53

tally1:close(); tally2:close()

await(finalCount)
//finalCount == 132

Reacting to multiple refs?

In the previously examined examples of reactive programming we have only considered the case of monitoring individual refs for changes. However, Concurnas supports monitoring of multiple refs at the same time. The following groupings of refs may be monitored in any of the reactive elements: await, every, onchange and async:

• Individual refs - Multiple individual refs may be referenced in a comma separated list:

    lhs int:
    rhs int:
    plusop = every(lhs, rhs){ lhs + rhs	}
  

  Multiple refs may be declared and assigned within the reactive element provided that the are in the comma seperated list, for example:

    lhs int:
    rhs int:
    plusop = every(a = lhs, b = rhs) { a + b}
  

• Arrays of refs - Multiple individual refs may be referenced in a array of refs:

    lhs int:
    rhs int:
    watchAr = [lhs rhs]
    plusop = every(watchAr){ lhs + rhs}
  

  The refs monitored are those present within the array upon creation of the reactive element in question. If the contents of the array changes post element creation these changes will not be included in the set of refs to be monitored. For monitoring of a dynamic set of refs, a ReferenceSet object is more appropriate.

• Lists, maps or sets of refs - Multiple individual refs may be referenced in a list or set of refs or the key set of a map:

    lhs int:
    rhs int:
    watchAr list<int:> = [lhs, rhs]
    plusop = every(watchAr) { lhs + rhs}
  

  As with likes of arrays of refs, only the refs present within lists, maps or sets of refs at the point of element creation will be included for monitoring. For monitoring of a dynamic set of refs, a ReferenceSet object is more appropriate.

• ReferenceSets - Instances of com.concurnas.runtime.cps.ReferenceSet can be used in order to monitor a dynamically changeable set of refs:

    from com.concurnas.runtime.cps import ReferenceSet
    lhs int:
    rhs int:
  	
    liveSet = new ReferenceSet()
    liveSet.add(lhs)
    liveSet.add(rhs)
  		
    numChanged = every(liveSet) { changed.getChanged().length }
  	
    liveSet.remove(lhs)
    //our every expression will continue to monitor only 'rhs' for changes...
  

  Either closing or removing a ref from the monitored ReferenceSet will result in it being no longer being monitored by the reactive element.

• A mixture of the above - Multiple instances of the aforementioned groupings of refs may be used in a reactive element provided that they are presented as a comma separated list:

    lhs int:
    rhs int:
    another1 int:
    another2 int:
    another3 int:
    watchAr = [another1 another2 another3]
    numChanged = onchange(lhs, rhs, watchAr) { changed.getChanged().length }
  

A reactive element listening to more than one ref will be awoken for execution if any of refs it monitors is changed.

There are some special considerations and tools to bear in mind when working with reactive elements monitoring more than one ref:

lhs int:
rhs int:
numChanged = onchange(lhs, rhs) { changed.getChanged().length }
//numChanged is a ref containing the number of refs changed in a transaction causing onchange to be triggered

from com.concurnas.lang.pulsar import Pulsar, RealtimePulsar
from java.time import Duration

trait TaskToDo{
  def doTask() void
}

inject class EventScheduler(pulsar Pulsar, task TaskToDo){
  def scheduleEvent(){
    tigger := pulsar.after(Duration.ofSeconds(10))//schedule event for 10 seconds time...
    every(tigger){
      task.doTask()
    }
  }
}

class HelloWorldTask ~ TaskToDo{
  def doTask(){
    System out println "Hello world!"
  }
}

provider Temporal{
  provide EventScheduler
  single Pulsar => new RealtimePulsar()//single as we wish use the same instance for all provided EventScheduler's
  TaskToDo => new HelloWorldTask()
}


schduler = new Temporal().EventScheduler()
schduler.scheduleEvent()

from com.concurnas.lang.pulsar import Pulsar, FrozenPulsar
from java.time import Duration

trait TaskToDo{
  def doTask() void
}

inject class EventScheduler(pulsar Pulsar, task TaskToDo){
  def scheduleEvent(){
    tigger := pulsar.after(Duration.ofSeconds(10))//schedule event for 10 seconds time...
    every(tigger){
      task.doTask()
    }
  }
}

class TestTask() ~ TaskToDo{
  -taskRun boolean:
  def doTask(){
    taskRun = true
  }
}

provider TemporalTest{
  provide EventScheduler
  single provide FrozenPulsar => new FrozenPulsar()//single as we wish use the same instance for all provided EventScheduler's
  single provide TaskToDo => new TestTask()//single for same reasons as above
}


tempoTest = new TemporalTest()
scheduler = tempoTest.EventScheduler()
scheduler.scheduleEvent()
task = tempoTest.TaskToDo() as TestTask

pulsar = tempoTest.Pulsar() as FrozenPulsar

//now we inject the current to our pulsar...
pulsar.currentTime = pulsar.currentTime + Duration.ofSeconds(10)
await(task.taskRun)//wait for task to be run and for this ref to be set with a value

Parfor?

Concurnas has support for parallel for loops in the form of a parfor loop. These are a convenient and intuitive mechanism for performing task based operations in the context of a loop, in parallel. The syntax of the parfor loop is the same as a regular C style for or Iterator style for except that the parfor keyword is used. parfor loop's may use index variable's but may not use may use else block's. parfor loop's may return values, the returned value shall be of type java.util.List<X:> where X is the ordinary type returned from the parfor block.

For example:

def gcd(x int, y int){//greatest common divisor of two integers
  while(y){
    x, y = y, x mod y
  }
  x
}

res1 = parfor(b in 0 to 10){
  gcd(b, 10-b)
}

res2 = parfor(b =0; b < 10; b++){
  gcd(b, 10-b)
}
//res1 == res2 == [10:, 1:, 2:, 1:, 2:, 5:, 2:, 1:, 2:, 1:, 10:]

The parfor loop operates by creating an isolate for each iteration upon which it's operating and adding it to a returned list of refs (if a return value is expected).

res1 = parforsync(b in 0 to 10){
  gcd(b, 10-b)
}
//exeuction of code below this point contingent on all isolates completed

//res1 == [10:, 1:, 2:, 1:, 2:, 5:, 2:, 1:, 2:, 1:, 10:]

res1 = gcd(b, 10-b) parfor b in 0 to 10
res2 = gcd(b, 10-b) parforsync b in 0 to 10

Which solution to use?

Concurnas, being a language designed from the beginning for building reliable, scalable, high performance concurrent, distributed and parallel systems presents a wealth of different options regarding computation. Here we present a brief summary of the different options available in Concurnas and what sorts of problems they are best and least (where appropriate) well suited to solving.

One important consideration to bear in mind with any Isolate based concurrency solution in Concurnas (parfor, isolates, actors and reactive programming) is that the cost(both in terms of programming effort and actual computational resources) of creating an isolate is non epsilon. Sometimes problems are of a degree of complexity that, even though they can be solved in a concurrent manner, they would be best suited to a single threaded solution for the cost of solving them in a concurrent manner would be greater, this is particularly acute for simple operations and/or small amounts of data. The effect is magnified when one introduces distributed computing - where we also need to consider a wider array of failure cases.

• For comprehensions

  For comprehensions are great in instances where we need a quick one line solution for iterating over elements of an iterable object with the potential for filtering. However, for comprehensions are not concurrent operations and so do not scale with processor cores even if our input data size to iterate over is large.

• Vectorization

  Vectorization is a nice convenient way of working with array like data in a very concise manner. Vectorization does not take advantage of the multi-core nature of modern CPUs and so on its own has the same disadvantages as for comprehensions. GPU computing is often a better alternative to numerical computing with vectorization, though the programming model can be more work up front.

• Java [parallel] streams

  Java streams present a large and very capable API for working with data. They even provide a parallel computation implementation which is based on traditional Thread based execution and hence does not take advantage of the Concurnas model of concurrent execution. Again, for CPU based problems GPU computing is often a better solution.

• Parfor

  Parfor is a great solution for when we need to implement an operation on each element of an iterable data structure and those instances do not need to interact with one another. They are a good solution for task based parallel problems - where lot of i/o, interaction with main memory, etc much take place. But for CPU based problems where much calculation is required, GPU programming is usually a better solution.

• Refs

  Refs are an integral part of, and help us utilize, other concurrent programming solutions in Concurnas. Refs are built around the concept of optimistic shared state. All writes and reads to refs are atomic, but their state is changeable and often nondeterministic. The optimistic model of computation breaks down somewhat where there is a large degree of contention on a shared ref. For this reason actors are often a better alternative where a ref is shared and contended between a number of isolates.

• Isolates

  Isolates, like refs form the basis of many of the concurrency primitives in Concurnas. On their own they are ideally suited to implementing task based solutions to problems.

• Actors

  Actors are ideal for cases where we need to implement controlled complex shared mutable state wrapped up within an object. If ever we find ourselves needing to share an object between isolates, then an actor is our answer. Since they effectively turn all requests of them into a single threaded execution chain, if we are not careful they can become bottlenecks in our applications. They are best suited to providing task based, discrete services for instance to i/o and/or controlled access to state.

• Reactive programming: await, onchange, every, async

  The reactive programming constructs offered by Concurnas are an excellent way of working with refs in order to solve reactive and temporal logic based problems in an intuitive and natural manner. Like most of the concurrency solutions in Concurnas they can be used for both task based and CPU based computation, though are better suited to solving task based problems.

• Transactions

  Transactions enable us to modify more than one ref in an atomic fashion. Care should be taken to make transactions as simple as possible and to avoid non idempotent side effects in their execution for they can be repeated as many times as necessary in order to complete a transaction. Transactions on high contention refs should be avoided, here actors are often a better choice.

• GPU computing

  GPU computing is ideal for CPU based execution where we must perform lots of the same operations upon a large data set. Compared to single core execution (e.g. using vectorization or for comprehensions) a speed up of 100x (two orders of magnitude) is often achievable when switching execution to the GPU! Though some extra engineering work is required in order to unlock this. Considerations to bear in mind when using GPU computing are that data transference to and from the GPU can be the bottleneck of many GPU based algorithms. The setup and clean up work required in order to utilize the GPU does require some attention. GPU computing is not appropriate for task based execution.

• Distributed computing

  Distributed computing is often the final step on the scalability path for our algorithms. Distributed computing allows our programs to run across hundreds of even thousands of computers. Concurnas makes distributed computing easy by virtue of its first class citizen support for this form of computing. Distributed computing is especially useful when accessing remote or shared resources (e.g. databases, high powered GPUS etc). Some additional engineering work is required over localized computing in that the failure landscape for distributed solutions to problems is larger.