[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] Posix threading
From: |
Peter Busser |
Subject: |
Re: [Chicken-users] Posix threading |
Date: |
Fri, 11 Mar 2005 09:41:08 +0100 |
User-agent: |
KMail/1.7.2 |
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.
- Re: [Chicken-users] Posix threading, (continued)
- Re: [Chicken-users] Posix threading, Toby Butzon, 2005/03/10
- Re: [Chicken-users] Posix threading, Julian Morrison, 2005/03/10
- Re: [Chicken-users] Posix threading, felix winkelmann, 2005/03/11
- Re: [Chicken-users] Posix threading, Julian Morrison, 2005/03/11
- Re: [Chicken-users] Posix threading, felix winkelmann, 2005/03/11
- Re: [Chicken-users] Posix threading, Peter Busser, 2005/03/11
- Re: [Chicken-users] Posix threading, Julian Morrison, 2005/03/11
Re: [Chicken-users] Posix threading, felix winkelmann, 2005/03/11
Re: [Chicken-users] Posix threading,
Peter Busser <=