Re: [9fans] "Blocks" in C

[David Leimbach <leimy2k@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3125 bytes --]

On Fri, Sep 4, 2009 at 7:20 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > I could be wrong, but I feel like you're not really interested in
> > entertaining that this idea could be useful, but more interested in
> shooting
> > it down [...]
>
> remember, if a guy says to the king, hey you're fly's undone,
> we send that guy to the stockades for a week.  meanwhile
> the king's fly remains undone.
>
> since the raison d'etre of blocks is ease of programming,
> i would think it would follow that it should be uniformly
> easier across the board.  if there are big exceptions to this
> (like extra locking), i would think the feature would earn
> a fail.
>
>
I am totally agreeing with you so far on all points you've just made.  And I
think that's why Apple is seeking feedback.  The advantage of the higher
level languages that were designed with concurrency in the language, is that
you don't feel like you're twiddling the bits manually so much to express an
algorithm.


> i'm just noting that if blocks require locking as you mention,
> then this is inferior to calling a function through a pointer.
>

Indeed.


>
> unless you don't accept more locking is worse, it's hard to
> argue this point.
>

My entire point is this will often allow you to get away with far less
locking, or at least, that's what the intention of all of this is.


>
> you can accuse me of hating, that won't change how blocks
> work.
>


I'm not saying you are hating on blocks, I said I'm beginning to feel as if
perhaps you're trying to find holes in it, but you keep saying things that I
don't think are true about them. For example, claiming that blocks require
more locking is evidently false if you look at example code that's been
provided.  DispatchLife, for example, includes contextual data pointing to
neighboring cells, and because of the serial nature of the queues involved,
it's impossible to have two threads updating the same shared data at once.

The story is different if you take those same blocks, and have them
scheduled to run on the global concurrent queue, in which case many of them
could be running at once.  So if you code it up incorrectly, you sure could
have to do some locking.  But if you take advantage of the (too many in my
opinion) abstractions provided that help to guarantee you will not need
locking, then you shouldn't need to do any explicit locking of shared state.

And that is exactly why Apple bothered to do all of this.  If not, they're
totally wasting their time, because, as you've said, to create something
that would require more locking is a big lose.



> > Deep down inside, I want people to stop trying to code stuff like this in
> C
> > and try the massively scaled parallelism/concurrency stuff in other
> > languages better suited to the problem space.
>
> why would you use c then?
>

Because if I wanted to write something for Mac OS X, and I needed it to work
with Grand Central Dispatch, I've not been provided a lot of options at the
moment to do anything else.

Dave

>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 4414 bytes --]