On Mon, 14 Jun 2010, Tomek Sowi?ski wrote: > Dnia 14-06-2010 o 21:27:24 Brad Roberts <[email protected]> > napisa?(a): > > > Const methods only prevent mutating 'this'. You can still call functions > > that mutate other state (via globals or passed in arguments). > > But synchronized on a method also protects only 'this', no?. Currently you can > have: > > class A { ... } > > shared class K { > synchronized void fun(A a) const { > // mutate a > } > } > > If you call fun on two instances of K, each in a different thread, but pass > them the same instance of A, you'll get a data race anyway. You could make > fun's arguments const, but still there's shared globals.
The lock is per-object but the lock protects all of the code inside the block, not just the parts that hang off the this reference. You're code describes the case I'm talking about. If the mutations to A are all inside the K::fun code, and your proposal happens, then code that runs safely changes to code that runs unsafely. I'm not saying it's a good idea to structure code that way, but the language rules need to consider all angles, not just the used correctly or best practices uses.
