On Fri, 04 Sep 2009 08:04:40 PDT David Leimbach <[email protected]> wrote:
> On Fri, Sep 4, 2009 at 7:41 AM, Bakul Shah
> <[email protected]<bakul%[email protected]>
> > wrote:
>
> > On Fri, 04 Sep 2009 00:47:18 PDT David Leimbach <[email protected]>
> > wrote:
> > > On Fri, Sep 4, 2009 at 12:11 AM, Bakul Shah
> > > <[email protected] <bakul%[email protected]><
> > bakul%[email protected] <bakul%[email protected]>>
> > > > 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.
:-)
