Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
If the problem is IO bound to a single, local, harddisk, and is uncacheable, then concurrency may not help.

Yes. I appreciated your detailed response.

(Fwiw, in my original comment I meant that a problem that is as you describe is really IO bound, and a problem that isn't, isn't.)

Only mathematicians and computer scientists demand total determinacy; and throw their arms up in refusal to work if they don't get it.

I think you've misinterpreted The Problem with Threads. The author was not demanding total determinacy (which I agree would be profoundly bogus). To quote from the abstract: "Nondeterminism should be explicitly and judiciously introduced where needed, rather than removed where not needed."

don't throw the baby out with the bath water. Flames are dangerous; but oh so very useful.

While your particular choice of metaphors has me imagining a complicated maneuver involving strong folk, an old fashioned bath, a gassy baby, a lighter, and some sort of worthwhile singeing operation, I don't think your point is that far adrift from (Perl) "should not hide the existence of OS-level threads, or fail to provide access to lower level concurrency control constructs".

Futures neither remove the complexity nor solve the problems; they just bury them under the covers forcing everyone to rely upon the efficacy of their implementation and the competence of the implementors.

I confess to being amazed by this statement. Are you really saying that, when solving any concurrent problem correctly (data-wise), Futures are never (or seldom) simpler for the programmers writing, reading, and modifying the code than directly using the underlying low level concurrency constructs (which I'll hand wavily define as threads, locks, cas, etc.)?

Do you think there are any very useful high level concurrency constructs?

The "heaviness" of P5 threading is a misnomer. The threads aren't heavy; the implementation of shared memory is heavy. And that could easily be fixed. ... They've basically stagnated for the past 8 or more years because p5p won't allow change.

I'd appreciate a link to a decent recent technical discussion of the problem of the heaviness of shared memory in P5 and reasonable potential fixes. Failing that, a couple paragraphs that summarize the problem and the fix you're suggesting would be great. Or maybe you could write a meditation that invites monks to focus on the technical issues related to the problem and potential fixes?

In reply to Re: The problem with "The Problem with Threads" by raiph
in thread The problem with "The Problem with Threads" by BrowserUk

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or or How to display code and escape characters are good places to start.
Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (3)
As of 2022-05-23 03:16 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (81 votes). Check out past polls.