wrote something on threads, which is ahead of time, so not linked in

crystal/threads.md

@@ -0,0 +1,78 @@
+---
+layout: news
+author: Torsten
+---
+
+Having just read about rubys threads, i was moved to collect my thoughts on the topic. How this will influence implementation
+i am not sure yet. But good to get it out on paper as a basis for communication.
+
+### Processes
+
+I find it helps to consider why we have threads. Before threads, unix had only processes and ipc, 
+so inter-process-communication.
+
+Processes were a good idea, keeping each programm save from the mistakes of others by restricting access to the processes
+own memory. Each process had the view of "owning" the machine, being alone on the machine as it were. Each a small turing/
+von neumann machine.
+
+But one had to wait for io, the network and so it was difficult, or even impossible to get one process to use the machine 
+to the hilt.
+
+IPC mechnisms were and are sockets, shared memory regions, files, each with their own sets of strengths, weaknesses and 
+api's, all deemed complicated and slow. Each switch encurs a process switch and processes are not lightweight structures.
+
+### Thread
+ 
+And so threads were born as a lightweight mechanisms of getting more things done. Concurrently, because when the one
+thread is in a kernel call, it is suspended.
+ 
+#### Green or fibre
+
+The first threads that people did without kernel support, were quickly found not to solve the problem so well. Because as any
+thread is calling the kernel, all threads stop. Not really that much won one might think, but wrongly.
+
+Now that Green threads are coming back in fashion as fibres they are used for lightweight concurrency, actor programming and
+we find that the different viewpoint can help to express some solutions more naturally.
+
+#### Kernel threads
+
+The real solution, where the kernel knows about threads and does the scheduling, took some while to become standard and 
+makes processes more complicated a fair degree. Luckily we don't code kernels and don't have to worry.
+
+But we do have to deal with the issues that come up. The isse is off course data corruption. I don't even want to go into 
+how to fix this, or the different ways that have been introduced, because the main thrust becomes clear in the next chapter:
+
+### Broken model
+
+My main point about threads is that they are one of the worse hacks, especially in a c environemnt. Processes had a good
+model of a programm with a global memory. The equivalent of threads would have been shared memory with **many** programs
+connected. A nightmare. It even breaks that old turing idea and so it is very difficult to reason about what goes on in a 
+multi threaded program, and the only ways this is achieved is by developing a more restrictive model.
+
+In essence the thread memory model is broken. Ideally i would not like to implement it, or if implemented, at least fix it
+first.
+
+But what is the fix? It is in essence what the process model was, ie each thread has it's own memory.
+
+### Thread memory
+
+In OO it is possible to fix the thread model, just because we have no global memory access. In effect the memory model 
+must be inverted: instead of almost all memory being shared by all threads and each thread having a small thread local 
+storage, threads must have mostly thread specific data and a small amount of shared resources.
+
+A thread would thus work as a process used. In essence it can update any data it sees without restrictions. It must 
+exchange data with other threads through specified global objects, that take the role of what ipc used to be.
+
+In an oo system this can be enforced by strict pass-by-value over thread borders. 
+
+The itc (inter thread communication) objects are the only ones that need current thread synchronization techniques.
+The one mechanism that could cover all needs could be a simple lists.
+
+### Crystal
+
+The original problem of what a program does during a kernel call could be solved by a very small number of kernel threads.
+Any kernel call would be listed and "c" threads would pick them up to execute them and return the result.
+
+All other threads could be managed as green threads. Threads may not share objects, other than a small number of system
+provided.
+