Re: [Chicken-users] Posix threading

[Peter Busser]

Hi!

> I'm not entirely certain, but I think Chicken's stack-based gc mechanism
> makes Posix threading impossible - am I right? Stack allocated stuff
> can't be visible across threads with seperate stacks, and heap allocated
> stuff can be moved by GC.

AFAIK the various POSIX threads have their stacks located in different parts 
of the single address space. You can easily test this with a program which 
starts two threads. Each thread writes a value to a local variable and then 
writes the pointer to that variable in a shared global variable. Then sleep 
for 1 sec. in each thread (to make sure they have both finished writing their 
own value) and print both values from both threads using a pointer 
dereference. They should both print two identical values. This would prove 
that one thread can access the other thread's stack.

> Perhaps Posix threaded programs could work, provided they only rely upon
> "evicted" shared data?

If each stack evicts its own stack, this means that the heap is accessed 
concurrently and needs to be protected against this, because it will lead to 
race conditions and therefore corruption.

> Posix threads are good because (1) they allow blocking kernel calls to
> only block one thread (2) they take full advantage of multiple CPUs,
> hyperthreading processors, etc.

POSIX threads are not always implemented as kernel threads. In fact, I think 
that Solaris and the Linux/GLIBC NPTL library use a mixture between kernel 
and user space threads. A kernel thread sounds nice at first, but in reality 
isn't. A user space thread can be implemented in a few function calls, wich 
introduces a low overhead.

A kernel thread is not just a function call. Scheduling to a thread means a 
context switch. And context switches are usually very very expensive compared 
to a function call. Roughly speaking a context switch adds 20-50x more 
overhead compared to a function call. That is, if you are lucky. The latest 
generation CPUs uses increasingly complex ways to improve the throughput, at 
the cost of also making context switches more complex and therefore more 
expensive, as the following LKML posting shows:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0301.0/1185.html

BTW, the following document: 
http://www.i.u-tokyo.ac.jp/ss/report/sun/Lecture-1-Tony-Printezis/GarbageCollection.pdf
provides a nice overview of the various GC techniques and their 
advantages/disadvantages.

Groetjes,
Peter.