From mboxrd@z Thu Jan  1 00:00:00 1970
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
In-reply-to: Your message of "Fri, 04 Sep 2009 08:04:40 PDT."
	<3e1162e60909040804y67b4f85en589bb5410f11a7cc@mail.gmail.com>
References: <3e1162e60909032118h60620d2cj74791672e5f55a5f@mail.gmail.com>
	<0084d6ddb9d674fa38925596dabc8d78@quanstro.net>
	<3e1162e60909032231h5a2cc329x89744a497052e551@mail.gmail.com>
	<3e1162e60909032235s6e5a67dau6109f30246f255d@mail.gmail.com>
	<20090904071109.11C405B18@mail.bitblocks.com>
	<3e1162e60909040047q2f3451e4k2880720beb2a1373@mail.gmail.com>
	<20090904144110.10C345B4B@mail.bitblocks.com>
	<3e1162e60909040804y67b4f85en589bb5410f11a7cc@mail.gmail.com>
From: Bakul Shah <bakul+plan9@bitblocks.com>
Date: Fri,  4 Sep 2009 08:58:25 -0700
Message-Id: <20090904155826.1A9BC5B4B@mail.bitblocks.com>
Subject: Re: [9fans] "Blocks" in C
Topicbox-Message-UUID: 64cc86e2-ead5-11e9-9d60-3106f5b1d025

On Fri, 04 Sep 2009 08:04:40 PDT David Leimbach <leimy2k@gmail.com>  wrote:
> On Fri, Sep 4, 2009 at 7:41 AM, Bakul Shah
> <bakul+plan9@bitblocks.com<bakul%2Bplan9@bitblocks.com>
> > wrote:
>
> > On Fri, 04 Sep 2009 00:47:18 PDT David Leimbach <leimy2k@gmail.com>
> >  wrote:
> > > On Fri, Sep 4, 2009 at 12:11 AM, Bakul Shah
> > > <bakul+plan9@bitblocks.com <bakul%2Bplan9@bitblocks.com><
> > bakul%2Bplan9@bitblocks.com <bakul%252Bplan9@bitblocks.com>>
> > > > wrote:
> > >
> > > > But this has no more to do with parallelism than any other
> > > > feature of C. If you used __block vars in a block, you'd
> > > > still need to lock them when the block is called from
> > > > different threads.
> > > >
> > > I just wrote a prime sieve with terrible shutdown synchronization you can
> > > look at here:
> > >
> > > http://paste.lisp.org/display/86549
> >
> > Not sure how your program invalidates what I said.  Blocks do
> > provide more syntactic sugar but that "benefit" is independent
> > of GCD (grand central dispatch) or what have you. Given that
> > __block vars are shared, I don't see how you can avoid locking
> > if blocks get used in parallel.
> >

To be precise, I meant to write "avoid locking if blocks get
executed in parallel and access a __block variable".

> You've said it yourself.  "if blocks get used in parallel".  If the blocks
> are scheduled to the same non-concurrent queue, there shouldn't be a
> problem, unless you've got blocks scheduled and running on multiple serial
> queues.   There are 3 concurrent queues, each with different priorities in
> GCD, and you can't create any more concurrent queues to the best of my
> knowledge, the rest are serial queues, and they schedule blocks in FIFO
> order.
>
> Given that you can arrange your code such that no two blocks sharing the
> same state can execute at the same time now, why would you lock it?

Consider this example:

    int
    main(int c, char**v)
    {
	int n = c > 1? atoi(v[1]) : 1000;
	__block int x;
	x = 0;
	parallel_execute(n, ^{ for (int i = 0; i < n; i++) ++x; });
	while (x != n*n)
		sleep(1);
    }

Where parallel_execute() spawns off n copies of the block and
tries to execute as many of them in parallel as possible.
Presumably this is implementable?  Will this prorgam ever
terminate (for any value of n upto 2^15-1)?  How would you
avoid sharing here except by turning parallel_execute() in
serial_execute()?

> I should note that for some reason my code falls apart in terms of actually
> working as I expected it after MAX is set to something over 700, so I'm
> probably *still* not doing something correctly, or I did something Apple
> didn't expect.

:-)