Such a thorough and well-reasoned explanation certainly should convince anyone.

Maybe, (and thanks), but the reality is that for many people who have come from Java and other multi-processing backgrounds, my explanation won't necessarily ring true, because it goes against much of what they were taught in colleges; or read in (often highly recommended) books (see the real time section:barriers; latches; exchangers) and on training courses.

There has been -- and still is in many circles -- far too much emphasis placed on synchronisation -- which creates all the bad guys of multiprograminig as listed under "Realtime Anti-Patterns". If you don't synchronise at all, none of the bad guys can happen.

(The difference between someone who’s cooking a hamburger, and the hamburger itself.)

I don't think your burger analogy helps much here. The problem lies not (so much) in work-unit .v. worker, but in how the workers communicate.

The best analogy I have is the difference between old-school voice mail; and those dratted call-center "Your message is in a queue and will be answered shortly - tick-tock -- We're sorry but due to the high volume of calls there are no free agents; please hold" queuing systems.

The problem is not the queue per se, but the synchronicity of that queue from the callers perspective. From the call center's perspective, it is an efficient way of distributing the workload. But from the caller's perspective, having to stand around listening to the typical "Your call is important to us..." lies is just dead, wasted cycles.

On the other hand, voice mail allows me to ask my question and get on with something else until an agent becomes free and calls me back. Ie. It is a (pair of) asynchronous queues.

Of course, the downside of that is the phone tag game. It can happen in bi-directional queuing also.

The solution is promises (also known as futures; also known as deferred synchronicity).

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?

In reply to Re^3: About self-invoked threads into class by BrowserUk
in thread About self-invoked threads into class by Omniperl

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


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.