[Chicago-talk] Fw: What problems do threads solve for you and how could your languagemake it easier

Steven Lembark lembark at wrkhors.com
Wed Oct 27 19:21:14 PDT 2010


On Tue, 12 Oct 2010 10:28:10 -0500
Andy_Bach at wiwb.uscourts.gov wrote:

> I really like the question:
> "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?"
> 
> in a language design sort of way - but I've not needed threads (save
> for on http related hack) so - anybody out there got any ideas?
> 
> Over on a P6 list: 
> 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?
> 
> 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?"
>
> 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.

The best use of thread's I've seen is in dealing with 
low-level I/O issues where a portion of the running 
collection can voluntarily give up the CPU to another
portion when it knows that the next machine instruction
will cause the collection to block during a timeslice.

Threads work wonderfully for this, and other kernel-level
tasks where many data struct's are accessed and blocking
is relatively common. 

None of which has anything to do with Perl -- unless 
someone is going to write Perlnix sometime soon?

For *NIX systems, forking will gracefully handle about
90% of the parallel execution issues; MSW doesn't support
true forks and has its own issues that threads might
support; VMS supports spawning which is far too expensive,
but still does most of what is needed; I don't know of 
anyone using Perl on a 360 mainframe with JCL.

What people want in threads is ususally the ability to:

 - spawn off some task to run in parallel.
 - easily have the task update a structure in memory.
 - then discard the task's context, or recyclce it for
   another task (a.k.a. "worker threads"). 

The downside to this is syncing the update points.

Perly shared memory requires not only locking the 
structure but serializing it so that the memory offsets
used in ref's are accessable to the forked process. With
threads you'd be able to access $foo->{ bar } without 
that overhead, at the expsen of locking $foo->{ bar }.

The biggest headache to threading is keeping track of 
the sync points. Previous perly threading attempts tried
to deal with this by making lexicals private to the thread
(still not so bad an idea) and bulk copying the shared
portion. Problem there was that it prevented the sharing 
we all wanted from threads in the first place. 

Aside from the issue of updating complex memory struct's,
there really isn't anything you can to with threads that
you cannot do with forks, and Perl already has good
support for forks on the systems that support them.

So, a problem description would be something like:

- Let's find a way to allow for parallel execution of 
  tasks in a Perl program that makes private variables
  simple and [largely] automatically deals with sync
  points and locking of the shared structures.

enjoi

-- 
Steven Lembark                                             3646 Flora Pl
Workhorse Computing                                   St Louis, MO 63110
lembark at wrkhors.com                                      +1 888 359 3508


More information about the Chicago-talk mailing list