Concurrency

[John Meacham]

On Mon, Apr 03, 2006 at 11:38:08AM +0100, Ross Paterson wrote:
> On Fri, Mar 31, 2006 at 01:15:03PM -0800, John Meacham wrote:
> > On Fri, Mar 31, 2006 at 04:21:26PM +0100, Simon Marlow wrote:
> > > Great.  Apart from my misgivings about allowing cooperative scheduling
> > > at all, here's a few comments on the proposal:
> > 
> > much much preferable to a standard that not everyone can implement. :)
> 
> Are there potential users for the compromise interface?  I had the
> impressions that those wanting concurrency needed the fairness
> guarantees.

quite the opposite IMHO. I think for most uses cooperative
implementations will be not just just fine, but preferable.

We really shouldn't call it a compromise interface, cooperative
threading is often considered superior to pthreads/pre-emptive threading
for a wide variety of tasks. After a lot of experience writing pthreads
code from both the OS and application side, I find I agree. cooperative
state-threads should always be the way to go by default when writing new
code unless you absolutely need one of the features of pre-emptive
threading.

the tasks for which state-threads work well for are IO bound
multiplexing tasks, pthreads are better for CPU-bound tasks. 

However, most uses of concurrency are for programs that interact with
the user or the external world, as in they wait for an event from a
variety of sources and respond to it quickly. The limiting factor isn't
processing power, but how fast the events come, how fast you can redraw
the screen, your network speed, etc.  exactly what state-threading is
best at. Most CPU bound tasks tend to be batch processing type things
like compilers, which don't need concurrency to begin with.

some info on the advantages and tradeoffs
http://state-threads.sourceforge.net/docs/st.html

although written from the point of view of network servers, a lot is
relevant to other fields. 

Ideally, I'd like to provide both in jhc. But cooperative is a whole lot
of bang for the buck.

        John



-- 
John Meacham - ⑆repetae.net⑆john⑈