Multi-threaded programming in general

Threading is a basic tool for tackling certain classes of problems within *any* programming task. Almost any program could utilise threading; it is just a case of whether there is any benefits from doing so; and whether those benefits are worth the effort required.

There are two basic problems that threading can potentially be usefully used to solve:

1. Utilising what would otherwise be "dead time" by doing something else whilst waiting for some other thing to finish.
2. Reducing overall runtime by spreading cpu-bound processing across multiple cores.

Within those two categories, could fall just about every program that has or will be ever written.

Multi-threading in Perl

The difficult part of threading using Perl, is adapting to its particular strengths and weaknesses.

• Strengths:
  • Simple API.

    It doesn't get much simpler than async{  #do stuff };

  • Only explicitly-shared data.

    Accidental sharing is (almost) impossible, which makes many of the caveats usually applicable to threading null & void.

• Weaknesses:
  • The requirements of explicit sharing mean that thread startup costs are relatively high.

    This can be seen as a strength: It quickly discourages naive programmers from "throwing threads at everything". A common trait amongst programmers new to languages that expose threading to them.

  • Shared memory is slow due to the needs of internals locking to ensure the integrity of Perl's internals.

    Again, this can be viewed as a strength in that it makes people think about only sharing what needs to be shared; rather sharing everythng and tying themselves in knots with elaborate and often, equally slow, locking and syncing mechanisms.

could you recommend a number of useful programming applications of threaded PERL that I could get to work on for this purpose ?

In a nutshull; no.

The problem with answering your question directly, is that it is analogous to asking how to use a frying pan: there are so many different ways of using them, picking out one or a few recipes (programs) that can make use of them is of little value. In every one of those cases, another pot could be substituted for the frying pan without having any major affect on the outcome of the recipe; and the list would necessarily ignore many other ways --eg. cracking nuts -- that can make use of them.

Hi BrowseUk Thanks for this insight. In practical terms, what this means to me is that I could take any common programming problem and try to implement it as threaded, thereafter evaluating the results compared to a non-threaded implementation.

I could take any common programming problem and try to implement it as threaded, thereafter evaluating the results compared to a non-threaded implementation.

Indeed. Though that could describe simply wrapping async{ ... }->join; around any existing program code.

A better starting point would be to think about the type of programs you usually write and how they might benefit from the use of threading.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?