[M3devel] [M3commit] how to switch userthreads on/off

[Jay]

 > But the memory allocator and garbage collector do it too, no? 

 

 

Right, the garbage collector runs a separate thread.

 


 > As for reaching the "thread locals", there is one slightly crazy 
 > idea that one could borrow from Sussman and Steele: add another 
 > implicit argument to every Modula-3 routine. In that argument, 
 > pass a pointer to the thread locals. For EXTERNAL calls (in or 


 

This is basically how it works already on many systems.

Just not FreeBSD <5, where there's no kernel thread support for managing

the register at thread switch time.

 

Look at the assembly code for __thread on FreeBSD 5.

 

Notice that they do dedicate a register to thread locals.

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.)

 

 

I'm hoping to lay most of the blame on FreeBSD 4.x pthread_get/setspecific.

But there is still setjmp lurking in there, even on PM3, no matter user or pthreads.

 

 

Do you have numbers for FreeBSD 5 PM3 vs. CM3 pthreads?

__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..

 

 

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?

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?

 

 

 - Jay

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090429/044ebbcf/attachment-0002.html>