Threads don't scale, processes do - Fibers

[Robert Jacques]

On Sat, 30 Aug 2008 10:35:10 -0400, Oliver Dathe <o.dathe at gmx.de> wrote:

>> This sounds synergistic with thin-locks. Although locking code would  
>> have to be moved into the thread class to allow polymorphism on how the  
>> lock's aquired. i.e. Thead.getThis.lock(heavy_lock)
>
> Polymorphism is already used for that. You could modify __monitor (or  
> (cast(void*)this)[1]) in an object to show to a struct with an interface  
> reference for lock() and unlock(). You can then synchronize(...) on  
> that, so I don't think you have to touch Thread for that. That is what  
> I've seen in tango.core.sync.Monitor.

I think we're misunderstanding each other. Your post suggests to me that  
before using any shared object in a fiber, you first convert the monitor  
to the fiber lock-yield type and then later convert the object back when  
you return it to normal code. Polymorphism of the object should not be  
used as you don't know a prior whether an object is executing on a thread  
or a fiber or both, hence my suggestion of using thread polymorphism and  
moving the thick-lock code there. The synergy with thin-locks is that both  
threads and fibers should be able to take a thin-lock using the same code.  
Then again, since the thin-lock looks up the thread id anyways, maybe it's  
a moot point.

>> I'd recommend reading about JCSP (and it's C# and C++ brethren) and  
>> occam / occam-pi (see: http://www.cs.kent.ac.uk/projects/ofa/kroc/ ).
>
> Thanks, but CSP seems to have very little connection to this.

I re-read your post and it looks like your really interested in scheduling  
and not the threading. I'd still recommend CSP simply for the  
implementations of user-land thread scheduling. (besides  
alternatives/selects are cool) I'll also mention stackthreads, if your  
looking for just a pure fiber library. And nanothreads got a 40%  
performance increase over windows fibers if I remember correctly, so it  
might be worth taking a look at. In D, there's also DCSP.

Also, futures are very efficient implementation wise, and would be easy to  
extend to take scheduling parameters, like a due date and/or profiling  
data (i.e. generated from play testing data or on the fly to determine  
which routines are typically slow and which are fast and to schedule  
accordingly)