<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
> But the memory allocator and garbage collector do it too, no? <BR>
<BR>
<BR>
Right, the garbage collector runs a separate thread.<BR>
<BR>
<BR> > As for reaching the "thread locals", there is one slightly crazy <BR> > idea that one could borrow from Sussman and Steele: add another <BR> > implicit argument to every Modula-3 routine. In that argument, <BR> > pass a pointer to the thread locals. For EXTERNAL calls (in or <BR><BR>
<BR>
This is basically how it works already on many systems.<BR>
Just not FreeBSD <5, where there's no kernel thread support for managing<BR>
the register at thread switch time.<BR>
<BR>
Look at the assembly code for __thread on FreeBSD 5.<BR>
<BR>
Notice that they do dedicate a register to thread locals.<BR>
So it is about the same as what you propose, but better because they use a wierdo (segment) register that otherwise was unused. (Most other architectures can afford to give up a regular register. The "better" part is specific to x86 having so few registers.)<BR>
<BR>
<BR>
I'm hoping to lay most of the blame on FreeBSD 4.x pthread_get/setspecific.<BR>
But there is still setjmp lurking in there, even on PM3, no matter user or pthreads.<BR>
<BR>
<BR>
Do you have numbers for FreeBSD 5 PM3 vs. CM3 pthreads?<BR>
__thread should be faster than pthread_get/setspecific, but pthread_get/setspecific are probably also way better with kernel threads vs. FreeBSD 4 usermode pthreads..<BR>
<BR>
<BR>
Olaf, your recall that FreeBSD userthreads were "fast"..is that based on FreeBSD 4.x by chance? Maybe they don't have much advantage on any other system?<BR>
You know...FreeBSD 4.x pthreads are also userthreads, not really a fair comparison maybe with other pthreads implementations and maybe give pthreads a bad name?<BR>
<BR>
<BR>
- Jay<BR>
<BR></body>
</html>