New Bound Threads Proposal

[Simon Peyton-Jones]

| >> *) It violates requirement #4 "The specification shouldn't
explicitly
| >> require lightweight "green" threads
| >> to exist."
| >> OK, I wrote that requirement, and I might be the only one who
cares.
| >> But I still think that the existance of lightweight threads should
not
| >> somehow become a feature of the Haskell language.
| >
| > Not a feature of Haskell 98, but we are talking about a
| > concurrency extension anyway.  In fact, I think, we should
| > have an Addendum that covers all concurrency support
| > (lighweight and OS threads) in one go.  If anything, this is
| > only going to make the overall system simpler.

This is a good point, and one we hadn't really understood before.  I
thought that P3 required green threads even less than P1 and P2, but
it's quite the reverse, which is a bit counter intuitive.


Thus motivated, I've sketched Proposal 4, which is a sort of combinatory
of P2 and P3.   Much simpler than P2, but addressing the concerns
Wolfgang raises.

The main difference relative to P3 is that a Haskell thread is 
	either unbound
	or bound to a native thread N

Like P2, it has the property that at most one Haskell thread can be
bound to a native thread N.  Also like P1 and P2, the unbound Haskell
threads can be executed one-per-native-thread, or by a pool of worker
native threads, as you please.

Unlike P2, there is no notion of an "associated" native thread, or of
"temporary binding" of a Haskell thread to a native thread.

Details in CVS, and in a Postscript file that I'll send separately (I'm
having trouble with my externally-visible web site).

Wolfgang, does this help?

Simon
| 
| It would be the first place where implementations of Concurrent
Haskell
| are required to provide lightweight threads. Also, I expect Concurrent
| Haskell to be here to stay for some time, so tying the concurrency
| extension to the implementation technique that happens to be
"standard"
| right now would IMHO still be a mistake.
| 
| >> *) Using the system requires a lot of knowledge of the thread
| >> allocation issues, as all thread management has to be done
manually.
| >> Special combinators like nonBlocking will have to be used far more
| >> often than the "threadbound" combinator of proposal #2.
| >
| > The FFI design so far has always tried to provide minimal
| > extensions.
| 
| Haskell so far has tried to be "safe" to use; this manual thread
| management is not safe, it smells like it's going to generate lots of
| bugs. This would be the first time that Haskell (+concurrency
| extension+libraries) is less safe than C (+OS libraries) in a
| particular area (threading). You just don't get that strange blocking
| behaviour in C.
| 
| It could even be argued that Proposal 3 is, in fact, not a minimal
| extension at all; If we have a multi-OS-thread Haskell implementation,
| we can implement Proposal 2 by
| 	threadbound = id
| ... but Proposal 3 can only be implemented by changing to a
| light-weight-thread based scheduler.
| 
| The explicit thread management of Proposal 3 requires run time systems
| to support situations where 3 Haskell threads are running in OS thread
| A, and two more Haskell threads are running in OS thread B. Who needs
| that, and what for?
| It also requires runtime systems to actually use the native thread
that
| a Haskell thread is bound to for it's execution (which happens to be
| the natural choice for GHC's implementation).
| 
| It should be possible to implement Proposal 2 for Hugs; my current
| impression is that Hugs' Concurrency implementation would have to be
| redone from scratch to support Proposal 3.
| 
| Cheers,
| 
| Wolfgang
|