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

use Perl Log In

Log In

[ Create a new account ]

jjore (6662)

jjore
  twists@gmail.com
http://perlmonks.org/?node=diotalevi

Journal of jjore (6662)

Friday February 09, 2007
01:12 PM

Allegedly, STM has huge drawbacks as a basis for concurrency

[ #32362 ]

Lamba the Ultimate at http://lambda-the-ultimate.org/node/2048 posted an article pointing to an article by Patrick Logan at http://patricklogan.blogspot.com/2007/02/misguided-road-not-to-be-travelled.html . I only know the shared memory+locks of most "normal" programming and have only slight experience with Mozart/Oz which I hear is somewhat close to Erlang's ideas of shared-nothing.

I thought this was an interesting discussion and wanted to cross-post it just to possibly see what reaction this kind of pushback has from the Perl 6 camp where STM seems to be the cat's meow.


List all Journal entries
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 p

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