Re: Mutex's, sheesh

["Johan Johansson" <johan2sson () gmail com>]

For reasons that aren't entirely obvious to me nothing I write seems
to be posted to the list. Just as well perhaps.

Have you had a look at Herb Sutter's Concur project? Besides having
the skill and clout to actually get somewhere he seems to share much
of your basic opinions in this matter. For instance, one design
principle is that "anything that mentions the word thread isn't at a
high enough abstraction level". Instead he's (I keep saying he since
I'm not aware of any other participants in the project but that's not
to say they don't exist) taken well-researched concepts such as
futures and continuations and IMHO rather elegantly added them to C++.

Now I know you're going to say "C++?" but given his background the
choice of language is hardly surprising and the case can be made that
it's as good a choice as any other.

I would send you a link to the project but Herb's website seems to
have gone missing.

j

On 9/27/06, Dave Aitel <dave.aitel () gmail com> wrote:
> > From this weblog here:
> http://www.knowing.net/CategoryView,category,Concurrency.aspx
> "Software development industry analysis by Larry O'Brien, the former
> editor of Software Development and Computer Language"
> """
> The CLR & JVM are based on abstract hardware. The virtual machines
> have some things which immediately jump out as, let's say, "tough" for
> parallelizability -- both have a model whereby separate threads are
> responsible for coordinating their own access to shared memory (i.e.,
> fields in objects). On the other hand, they have at least one thing
> which jumps out as potentially a "very good" thing for
> parallelizability -- their stacks are conceptually separate from main
> memory, which may make the threading models easier to evolve (in a
> world without pointers, data in the stack is inherently local to the
> current thread.) The "inherently parallelizable" aspect of functional
> languages arises from their exclusive use of the stack for volatile
> state, but with the way the stack is generally conceived (as, y'know,
> a stack) requiring pushing and popping and copying variables from one
> to another, problems arise when copying large datastructures; thus my
> thought that maybe the abstraction of the stack could be a "win."
> """
>
> My thinking lately is this: that programming with types is a basically
> dumb thing to do. I know a lot of other people disagree, but having a
> runtime-defined type (as Python, etc do) is a hundred times better
> than having compile-time types.The people who disagree with this are
> all people who write in J2EE or C# and are managing truly massive
> projects. They have boring jobs, so good luck to them.
>
> For any serious program ten years from now, Python isn't going to cut
> it. Not because it's not scalable enough, but I think the very concept
> of scalability is going to change. A language should really be
> agnostic as to how many computers its running on and storing its data
> on, and it should be agnostic as to where those computers are on the
> Internet. Any language with a threading model is broken by design.
>
> It's like when the Python guys realized they didn't want to care how
> many bits were in an Integer, so they just made it a big number by
> default. You shouldn't care about mutex's and locking. It's just silly
> and backwards.
>
> http://scalability.org/?p=106#more-106 has a quick rundown of the
> state of things in the parallel programming world.  In general -
> pretty hard core on optimizing for CPU, which, history tells us, is
> the wrong thing to do. We need to optimize by programmer hours
> instead.
>
> OpenMP article
> http://www.devx.com/amd/Article/32246
>
> Reading list on parallel programming languages
> http://www.cs.cmu.edu/~scandal/parallel-lang/reading-list/reading-list.html
>
> I haven't read all those papers yet (still have two new MSRPC bugs to
> QA for next week - VERDE and an Exchange DoS I demoed at XCon 2006) ,
> but I'm left with the feeling that there's something missing. A
> primitive. Like "class" or "object" or "variable". Tomarrow's language
> shouldn't say "Everything is an object" and feel proud about it. It
> should say "Everything is an Actor" perhaps.
>
> -dave
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunitysec com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave