From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <9fe2df93f80bf5bea9bf494f1436edf0@quanstro.net> References: <3e1162e60909040652y5504130dqc7bc737452193ad5@mail.gmail.com> <9fe2df93f80bf5bea9bf494f1436edf0@quanstro.net> Date: Fri, 4 Sep 2009 07:56:15 -0700 Message-ID: <3e1162e60909040756r3e114e84v82412406620d22cc@mail.gmail.com> From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000e0cdf14b6abd6750472c1b31c Subject: Re: [9fans] "Blocks" in C Topicbox-Message-UUID: 64c32a98-ead5-11e9-9d60-3106f5b1d025 --000e0cdf14b6abd6750472c1b31c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 4, 2009 at 7:20 AM, erik quanstrom 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 > > --000e0cdf14b6abd6750472c1b31c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 4, 2009 at 7:20 AM, erik qua= nstrom <quans= tro@quanstro.net> wrote:
> I could be wrong, but I feel like you're not rea= lly interested in
> entertaining that this idea could be useful, but more interested in sh= ooting
> 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. =A0meanwhile
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. =A0if 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. =A0And I think that's why Apple is = seeking feedback. =A0The 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.
=A0
i'm just noting that if blocks require locking as you mention,
then this is inferior to calling a function through a pointer.

Indeed.
=A0

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

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

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 y= ou'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 bee= n provided. =A0DispatchLife, for example, includes contextual data pointing= to neighboring cells, and because of the serial nature of the queues invol= ved, it's impossible to have two threads updating the same shared data = at once.

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

And that is exactly why Apple bothered to do all of thi= s. =A0If not, they're totally wasting their time, because, as you'v= e said, to create something that would require more locking is a big lose. = =A0



> 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. =A0

Dave=A0

- erik


--000e0cdf14b6abd6750472c1b31c--