On Thu, Sep 3, 2009 at 2:45 PM, David Leimbach <leimy2k@gmail.com> wrote:


On Thu, Sep 3, 2009 at 2:35 PM, erik quanstrom <quanstro@quanstro.net> wrote:
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.


Maybe if you see the block implementation you wouldn't think it was merely naming a function pointer?

http://clang.llvm.org/docs/BlockImplementation.txt


also

{
 int X;
 call_a_block(^(int y) {print (X+y); });
}

The block has a snapshot of that stack variable "X".  

It really does work a bit more like a closure than a function pointer.

Dave
 
Dave
 
- erik