On Wed, Jul 31, 2013 at 10:44 AM, Jonathan S. Shapiro <[email protected]>wrote:
> The problem is that the slot containing the *reference* to the vector is > mutable. > I don't understand why these concurrency issues are getting dragged in. I really dislike the idea of the bare runtime enforcing concurrent behavior interactions. I respect shared nothing concurrency but dislike it. Having concurrent loops somehow mucked with because someone else wrote the field? Yuck. I'm 100% okay with the existing common reference semantics that say my loop operates over the concrete vector which existed when the loop began. As long as that vector doesn't disappear underneath me (which it wont because I hold an independent pointer to the box on my stack), then I'm fine. All this commentary about the field-mutability is mixing in concurrency issues which IMO should be addressed by concurrency primitives, not the loop code generation. When I am addressing concurrency I can specify the behavior and write the code to produce the desired result. Most commonly to avoid the collision ever happening, but sometimes perhaps invalidate the iterator and throw an exception if the field is mutated. IMO, with mutable-data, addressing partial/torn record updates in the value-array is a bigger concurrency challenge than the above issue.. since it often dictates we make any value-arrays locked during writes. STM and/or deep-immutable COW might be interesting here, and would also not affect the loop code-generation -- since now the loop would be operating not only on the field as of when it started, but also a snapshot of the data from when it started. > You might think that making a stack-allocated copy of the vector reference > would help, because *that* really *is* a single-thread slot. Except that > one thread can engage stack introspection on another, so actually it isn't > clear whether that helps. And note that if it *does* help, that raises > interesting optimization precondition quandries for termporary introduction > during rewrites. > Is this about the implications of optimizations on stack introspection/reflection/modification? Such as if you introspect and change a variable in the stack through introspection (maybe for a debugger)? I suppose it depends what level of changes are allowed. Probably simpler to revert to a non-optimized version of the code. I'm not very familiar with these details. If it's a structured increment loop (1 to 10 by n), it seems easy to hoist >> the range check and inline/unroll. >> > I agree that it *seems* easy. Unfortunately, the operative word here is > "seems". One of the hard parts of optimization is making sure that you've > captured all of the preconditions for the optimization to be correct. In > this case, a subtle set of non-local precondition requirements are getting > in the way. > Since I reject this notion of concurrent field-changes mucking with my loops, I'm curious if there are other things getting in the way.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
