From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <9ec1e4e59a6d111588ad2a506f1bb5e2@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu,  3 Sep 2009 17:35:12 -0400
To: 9fans@9fans.net
In-Reply-To: <1252012116.16936.5128.camel@work.SFBay.Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] "Blocks" in C
Topicbox-Message-UUID: 62c69edc-ead5-11e9-9d60-3106f5b1d025

On Thu Sep  3 17:09:01 EDT 2009, rvs@sun.com wrote:
> Anything can be done using regular C and threads. The trick here
> is to make everything *scalable* and *painless* enough so that
> mere mortals can start benefiting from parallelism in their code.
>
> The other trick here is to find a model that makes things *natural*, and
> that means practically no explicit locking, less shared state, etc.
>
> The search for the model is meaningless unless it is used for
> solving *practical* challenges. In that respect, one of my
> favorite article is how implementation of a chess engine
> influenced Cilk framework (which almost has the notion of a "block")
>    http://supertech.csail.mit.edu/papers/icca99.pdf
>
> Read it, I don't think we can be on the same page (and escape the
> armchair philosophy trap) unless we are talking about practical
> applications of the framework.
>
> Look at the chess example -- can the same be done with pure C? Sure!
> Did Cilk make it less painful? Absolutely!

my question was, what's naming your function pointers
or not got to do with locking?  i'm asking about the language
construct, not the library er i mean "framework" and maybe runtime
that goes with it.

- erik