[toronto-lisp] April meeting minutes available on the website

[Paul Tarvydas]

On Wednesday 15 April 2009 10:26:26 am Vishvajit Singh wrote:
> Ouch.. 89 threads?
> 
> I was confused about agents, apparently.. it seems that:
> 
> send -> runs on the thread pool
> send-off -> creates a new thread
> 
> Mea culpa :)

Not so fast :-).

I just finished watching the concurrency screencast, but the exact answer isn't in there.

Here is what I think he might be saying:

A classical (preemptive) process requires that you carve out a piece of memory for the stack and the context for the process.  If you have 300 processes, then you have 300 stacks.  If you have only one CPU, then 299 of the stacks are idly wasting space.  (This is one of the reasons why people resort to uglyosities such as thread pools).

In VF and stackless programming (and maybe in Clojure, given the statement about millions of agents in memory), there is only one stack - the hardware stack.

In VF, each instance of a part uses up only enough memory for two queues (due to VF semantics) and a flag[+].  VF parts - basically state machines - run each action to completion.  Parts all share the same stack and they leave no stacked context lying around "for next time".

To run a set of parts, you need a thread of execution.  The thread of execution winds its way through all of the activated parts and then dies out when there's no work left to perform.

On bare hardware, the thread of execution is provided by a hardware interrupt (if the hardware supports prioritized interrupts, you can have more than one thread of execution stacked up).

On an O/S, a thread of execution is whatever you want it to be, e.g. a user process or a thread.

If you wanted to spray the threads of execution across a bunch of CPU's, you would have to have at least one thread of execution on each of the CPU's.

I wonder if this is what Hickey is getting at?  The JVM will schedule threads onto various CPU's.  In the concurrency screencast, he uses a dual core machine and shows that his simulation is using more than 100% of the CPU (i.e. more than one core is active).

His ant simulation could benefit from the addition of CPU's, up to 89 of them.

He stresses (repeatedly) that there is no explicit locking in the user-written code.  He stresses that the GUI would be extremely hard / wasteful to write using locks.  The GUI takes a snapshot in time of the 80x80 world and then renders this snapshot on the screen.  According to him, it never gets it wrong - there are always the correct number of ants on the screen, they never overlap, etc.

pt


[+] Plus any static state variables declared by the programmer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/toronto-lisp/attachments/20090415/4bf94dff/attachment.html>