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