Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re^4: Parrot, threads & fears for the future.

by shmem (Chancellor)
on Oct 23, 2006 at 14:33 UTC ( [id://580052]=note: print w/replies, xml ) Need Help??


in reply to Re^3: Parrot, threads & fears for the future.
in thread Parrot, threads & fears for the future.

Son? Hmm, well. I just happen to be some silly 11 days older and sillier than you {g}.

You may have been a bit longer in this business than I (who came to computers off studying architecture around 1989) but I haven't been asleep in the meantime. I also remember the times when a good word processor on the Atari ST (RIP) was worth ~250kBytes on disk; I had my first perl experience with v4.36, and was glad and proud with my simple coding and delighted with Gurusamy's port to the Atari.

That's for that, Father ;-)

But as for threads - set apart the usefulnes of threads, your statement "threads in unix are spelled fork" is blatantly wrong. Threads were invented for a reason which shurely didn't escape you. Which reason? There.

Do threads solve the issues they address, and at which price? Here we might start a discussion, not just saying "threads suck" ("No, they don't suck." - "Yes, they do!" -"NO!") and throwing in false statements in an inflamatory way.

While I also never had the need to use threads, did all I had to do with fork or an event driven model (Event back then, then POE) - so I'm included in that "we were accomplishing" -, I also have to say that "Using threads are like using globals" is misleading, that would be more appropriate "using threads is like using our()".

I agree with you saying "Using fork is like having everything be local to its code and data", which is fine as long as you just want it that way and never ever are in need of shared variables. If you need shared data, you have the option of delegating the data to an external instance or to share it somehow via classical IPC mechanisms, shared memory segments, message queues, pipes and such - but you basically need the same synchronisation mechanisms as with threads (in come semaphores), and sharing complex data structures is IMHO some hells more difficult using IPC.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Replies are listed 'Best First'.
Re^5: Parrot, threads & fears for the future.
by merlyn (Sage) on Oct 23, 2006 at 17:32 UTC
    If you need shared data, you have the option of delegating the data to an external instance or to share it somehow via classical IPC mechanisms, shared memory segments, message queues, pipes and such - but you basically need the same synchronisation mechanisms as with threads (in come semaphores), and sharing complex data structures is IMHO some hells more difficult using IPC.
    But that's actually a good thing. The fact that it's a pain to share complex structures will make you rethink your application. If it's easy to share complex data, you'll end up taking a performance hit, because more and more of the data has to be locked because you're doing it blindly.

    And the default should be not shared, rather than shared. fork() ensures this. Threads is biased towards shared.

    Multiple threads of execution is hard. It should stay hard. There's really no way to make it easy. "threads" pretends to make it easy, and what you end up with are fragile programs because average dudes get in over their head. At least with fork, it's a pain to share things, so average dudes delegate the tricky parts to libraries that do the sharing written by smart dudes, or figure out other ways, like sharing through databases.

    Maybe that's why I object to threads: it makes it too easy to get in over your head. It takes far more expertise to use threads than most people have, which is less than they think they have. {grin}

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

      Multiple threads of execution is hard. It should stay hard.

      Maybe we should rewite all multiple threads related code in Malbolge, to fend off the clueless.

      There's really no way to make it easy.

      I question that. I think it's not much more difficult to outline the concepts of threading and it's implications in a coherent way, than it was with fork() or exec() back in now forgotten years.

      "threads" pretends to make it easy, and what you end up with are fragile programs because average dudes get in over their head.

      That might be a sad fact, but I strongly disagree with leaving things impenetrable to the average dude. Remember, the Average Dude State is a transitional, even if the average dude doesn't overcome average dudeness in their lifetime. Let the average dude burn 'til enlightenment.

      At least with fork, it's a pain to share things, so average dudes delegate the tricky parts to libraries that do the sharing written by smart dudes, or figure out other ways, like sharing through databases.

      Plain average dudes like myself and little Joe who always was interested in how that damn thing works rip themselves up to get it, to get at their aims and do things right. The average dude which delegates the tricky part to libraries written by smart dudes is a lousy dude if he trusts just out of the wrong type of laziness. It's more apt to the smart dude to delegate, because he knows what to delegate when to whom, and he fully understands him to whom he delegates.

      Maybe that's why I object to threads: it makes it too easy to get in over your head. It takes far more expertise to use threads than most people have, which is less than they think they have. {grin}

      No, merlyn, I disagree, though not strongly - or maybe strongly, but orthogonal to your views.

      My rules of thumb, for myself

      • don't do anything seriously (at work; for others) you can't grok entirely and can take responsability for
      • choose the right tools for the task at hand, don't use those tools until you understand how they work
      • if you don't know which tools to use, ask for advice (which I often don't do) or figure out
      • get burnt, bitten, hit and cursed as much as possible the rest of your time to prepare yourself for the next big leap of knowledge.
      • "care of the cow brings furthering" as the I Ching sayeth; keep rumiating things until you forget them; the ordering of knowledge in your mind is a digestive process; don't forget to forget...

      and with regard to knowledge (or personal) growth

      • there's nothing more adverse to growing than anaemic sancticity
      • perhaps more adverse to growing is a master's advice which binds you to mediocrity

      Real expertise is directly proportional to the love for the subject. You are doing all an ill favour - given the reputation you have - in condemning the use of threads, or trying to reserve the related knowledge to The Really Clueful. Reminds me a bit of those eggheads in white pinafores in the last century...

      I don't know why I get a Déjà-vu feeling with all that... may be related to an old thread I can't remeber now.

      cheers,
      --shmem

      _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                    /\_¯/(q    /
      ----------------------------  \__(m.====·.(_("always off the crowd"))."·
      ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://580052]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chanting in the Monastery: (4)
As of 2024-03-28 21:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found