On Fri, Sep 4, 2009 at 7:41 AM, Bakul Shah > wrote: > On Fri, 04 Sep 2009 00:47:18 PDT David Leimbach > wrote: > > On Fri, Sep 4, 2009 at 12:11 AM, Bakul Shah > > < > bakul%2Bplan9@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. > 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? What I did was allocate context data for the actual read end of a pipe fd on the heap, such that when an associated block was launched by the runtime (when something was written to the write fd of a pipe) it would get it's context pointer in it's block struct, which I could access by get_context. 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. Dave