On Tue, Oct 12, 2010 at 07:22:33AM -0700, Damian Conway wrote: > Leon Timmermans wrote: > > > For the love of $DEITY, let's please not repeat ithreads! > > $AMEN! > > Backwards compatibility is not the major design criterion for Perl 6, > so there's no need to recapitulate our own phylogeny here. > > The problem is: while most people can agree on what have proved to be > unsatisfactory threading models, not many people can seem to agree on > what would constititute a satisfactory threading model (or, possibly, models). > > What we really need is some anecdotal evidence from folks who are actually > using threading in real-world situations (in *any* languages). What has worked > in practice? What has worked well? What was painful? What was error-prone? > And for which kinds of tasks? > > And we also need to stand back a little further and ask: is "threading" > the right approach at all? Do threads work in *any* language? Are there > better metaphors?
A more general metaphore would be asynchronous tasking, a thread being a long running "implicit" task. Other issues include memory consistency models, tasking "granularity", scheduling, and flexible synchronization options. I am coming from the OpenMP world, so a lot of this falls on the shoulders of the runtime - a clear strength of Perl IMHO. It may be worth someone taking the time to read what the OpenMP spec has to say about tasking as well as exploring tasking support on Chapel, Fortress, X10, and Cilk. PGAS based languages may also offer some inspirations as a potential alternative to threads or tasks. The only scriping language that I know that supports threading natively is Qore. I've mentioned this before. Perl's functional aspects also make it fairly easy to create concurrency without the worry of side effects, but not everyone is lucky enough to have a loosely coupled problem or not need i/o. Now how to distill what's been learned in practice into a Perlish approach? > > Perhaps we need to think more Perlishly and reframe the entire question. > Not: "What threading model do we need?", but: "What kinds of non-sequential > programming tasks do we want to make easy...and how would we like to be > able to specify those tasks?" There are something like 12 HPC "domains" that have been identified, all needing something a little different from the compiler, runtime, and platform - these do not include things for which Perl is often (ab)used. > > As someone who doesn't (need to) use threading to solve the kinds of > problems I work on, I'm well aware that I'm not the right person to help > in this design work. We need those poor souls who already suffer under > threads to share their tales of constant misery (and their occasional > moments of triumph) so we can identify successful patterns of use > and steal^Wborg^Wborrow the very best available solutions. Are you sure you couldn't use threading over shared memory? :) Cheers, Brett > > Damian -- B. Estrade <estr...@gmail.com>
