Plumbing for the Arduino

To create multiple TVMs I initialize multiple contexts in the wrapper (initially using pthreads). This presents many challenges because if I were to naively create four TVM, for example, I would have four independent runtimes and a single occam program would actually be run four times in parallel. To handle this the initial thought was to have certain pointers in each context point to the same thing as the original context. While doing this we decided to initialize the contexts as they are need, moving the creation of new contexts to within the scheduler so when something was added to the scheduling queue a new thread was created. Because thing are only added to the queue when parallel occam processes are created this prevents waist by not creating extra TVMs until they are needed.

Currently I have run into several problems in my attempts to do the above mentioned steps. The first issue is with getting the pointer in the context to point to the right thing. Currently I create one context and then every time a new context is created I set the pointers of the new context equal to those in the old context. While in theory this should work, I clearly have some implementation issue. The code which does this is below.

Because the code to create a context is in the wrapper but I am now creating new contexts in the scheduler the function for starting a context but be available. To handle this I created a new pointer in the context (which is available to everybody) which points to the function that needs to be called. However I am having similar trouble with this aspect of the code.

Example:

Where ea is an array of pointers to execution contexts (ea[0] reserved for firmware)

121
122 ea[1]->spawn_hook = ea[n]-> spawn_hook;
123 ea[1]->spawn_hook = run_multicore;
124

run_multicore is a function defined above these lines and spawn_hook is a function (pointer) defined in the execution context struct.

However if I print the value of the pointers they are different. I have a similar problem with int and other pointers within the context struct. But because the pointers being shared across contexts refer to dynamic location, for example as the queue changes state all the pointers must change, I need to be able to set and forget them and know that all contexts will be pointing to the right place at all times, which I thought was the whole point of pointers. This question may demonstrate my clear lack of understanding when it comes to the see language and any comments or thoughts people have are warmly welcomed.

Greetings Internet, as  an undergraduate student at Allegheny College I am required to undertake a senior thesis project. I have hijacked this blog to share with you what I am doing so that you too can enjoy the roller coaster that is software development.

The goal of my project is to implement a multicore scheduler for the process oriented programing language occam (and occam-pi). Currently occam is run on a portable virtual runtime based on the transputer. This run time, implemented in c, is called the transterpreter and consists of one or more transterpreter virtual machines or TVM’s. Despite the massively parallel nature of the occam language the current Transterpreter is a single execution thread with no support for sharing work over more then one core of a processor. My work will replace the current scheduling algorithm with one designed for process oriented programing on multiple cores.

I will implement the scheduler in three steps, the first step will create an environment to work on the scheduler using posix threads (pthreads). I will create multiple TVMs running on different threads, in this way I can simulate the different cores by scheduling processes to the different TVMs. This first step will also give me time to get acquainted with the system and force me to learn some of the ins and outs of the transterpreter.

The Second step will be to implement the scheduler it’s self, which is a wait-free work stealing algorithm developed by Carl Ritson. Ritson’s current scheduler uses CCSP which requires access to native libraries so in this step I will port his scheduler to the transterpreter using the pthreads I set up in the first step rather then CCSP or other non-portable implementation tools.

While pthreads are completely portable they are also very heavy relative to other lower level processes, for this reason the final step will be to eliminate the use of pthreads and instead use LLVM which stands for low level virtual machine. The idea is that a program compiled for LLVM can run on any architecture which has an LLVM back end. Using LLVM will provide portability without forcing us to use higher level less efficient methods of implementation (such as pthreads).