Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Allegedly, STM has huge drawbacks as a basis for concurrency 4 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • <audreyt> Limbic_Region: well, the point is valid, that share-everything has drawbacks
    <audreyt> STM fixes the drawbacks to a degree but still if you can design the code to share nothing, the better
    <audreyt> not really sensational :)
    <allbery_b> he's right, share-nothing is ideal.  so's world peace.  both are about equally likely...
    • It's not really "STM has huge drawbacks as a basis for concurrency", but rather "sharing data among concurrent processes creates complexity" -- In practice, when it's desirable to have _some_ data shared, STM is one of the best way we know about to manage that complexity.

      • Agreed. The goal here in language design may be to encourage shared-nothing where it's appropriate (that is, almost everywhere) and making shared-something much less dangerous where it's absolutely necessary.

        • Yup. And I think having fork and async being the triggers for the two sharing models, respectively, and enable "my $x is shared" work transparently across forked processes, may be a fruitful way to go.

          Also, GHC 6.8 will come with a unified thread/event model [upenn.edu] that let people flip between explicit-sharing event "view" and implicit-sharing thread "view" freely, instead of maintaining an adhoc per-thread event queue; this also greatly simplifies asynchronous programs, while preserving linearly-scalable SMP performance.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.