links in the thread page

2014-07-28-active-objects.md

@@ -0,0 +1,71 @@
+---
+layout: site
+author: Torsten
+---
+
+Part of what got me started on this project was the intuition that our programming model is in some way broken and so by 
+good old programmers logic: you haven't understood it til you programmed it, I started to walk into the fog.
+
+### FPGA's
+
+Don't ask me why they should be called Field Programmable Gate Arrays, but they have facinated me for years, because off 
+course they offer the "ultimate" in programming. Do away with fixed cpu instruction sets and get the programm in silicon.
+Yeah!
+
+But several attempts at learning the black magic have left me only little the wiser. Verlilog or VHDL are the languages that
+make up 80-90% of what is used and they so not object oriented, or in any way user friendly. So that has been on the long
+list, until i bumped into [pshdl](http://pshdl.org/) by way of Karstens [excellent video on it](https://www.youtube.com/watch?v=Er9luiBa32k). Pshdl aim to be simple and indeed looks it. Also similuation is exact 
+and fast. Definately the way to go Karsten!
+
+But what struck me is something he said. That in hardware programming it's all about getting your design/programm to fit into
+the space you have, and make the timing of the gates work.
+
+And i realized that is what is missing from our programming model: time and space. There is no time, as calls happen 
+sequentially / always immediately. And there is no space as we have global memory with random access, unlimited by virtual
+memory. But the world we live in is governed by time and space, and that governs the way our brain works.
+
+### Active Objects vs threads
+
+That is off course not soo new, and the actir model has been created to fix that. And while i haven't used it much, 
+i believe it does, especially in non techie problems. And [Celluloid](http://celluloid.io/) seems to be a great
+implementation of that idea.
+
+Off course Celluloid needs native threads, so you'll need to run rubinius or jruby. Understandibly. And so we have 
+a fix for the problem, if we use celluloid.
+
+But it is a fix, it is not part of the system. The system has sequetial calls per thread and threads. Threads are evil as
+i explain (rant about?) [here](/kide/threads.html), mainly because of the shared global memory. 
+
+### Messaging with inboxes
+
+If you read the rant (it is a little older) you'll se that it established the problem (shared global memory) but does not
+propose a solution as such. The solution came from a combination of the rant, 
+the [previous post](/2014/07/17/framing.html) and the fpga physical perspective.
+
+A physical view would be that we have a fixed number of object places on the chip (like a cache) and as the previous post
+explains, sending is creating a message (yet another object) and transferring control. Now in a physical view control is
+not in one place like in a cpu. Any gate can switch at any cycle, so any object could be "active" at every cycle (without
+going into any detail about what that means).
+
+But it got me thinking how that would be coordinated, because one object doing two things may lead to trouble. But one of
+the Sythesis ideas was [lock free synchronisation](http://valerieaurora.org/synthesis/SynthesisOS/ch5.html) 
+by use of a test-and-swap primitive.
+
+So if every object had an inbox, in a similar way that each object has a class now, we could create the message and put it
+there. And by default we would expect it to be empty, and test that and if so put our message there. Otherwise we queue it.
+
+From a sender perspective the process is: create a new Message, fill it with data, put it to receivers inbox. From a 
+receivers perspective it's check you inbox, if empty do nothing, otherwise do what it says. Do what it says could easily
+include the ruby rules for finding methods. Ie check if your youself have a method by that name, send to super if not etc.
+
+In a fpga setting this would be even nicer, as all lookups could be implemented by associative memory and thus happen in one
+cycle. Though there would be some manager needed to manage which objects are on the chip and which could be hoisted off. 
+Nothing more complicated than a virtual memory manager though.
+
+The inbox idea represents a solution to the thread problem and has the added benefit of being easy to understand and 
+possibly even to implement. It should also make it safe to run several kernel threads, though i prefer the idea of
+only having one or two kernel threads that do exclusively system calls and the rest with green threads that use 
+home grown scheduling.
+
+This approach also makes one way messaging very natural though one would have to inent a syntax for that. And futures should
+come easy too.

_layouts/kide.html

@@ -15,6 +15,7 @@ layout: site
   		<ul class="nav nav-list">
         <li><a href="/kide/layers.html"> Layers of Kide </a> </li>
         <li><a href="/kide/memory.html"> Memory </a> </li>
+        <li><a href="/kide/threads.html"> Threads </a> </li>
         <li><a href="/kide/optimisations.html"> Optimisation ideas </a> </li>
   		</ul>
 		</div>

kide/threads.md

@@ -1,5 +1,6 @@
 ---
-layout: site
+layout: kide
+title: Threads are broken
 author: Torsten
 ---