On Friday, October 11, 2013 20:04:57 Sean Kelly wrote: > On Friday, 11 October 2013 at 17:50:26 UTC, Dicebot wrote: > > How can one possibly used "synchronized" for this in absence of > > classes if desire behavior is to lock an entity, not statement > > block? > > I'm not sure I follow. But I was in part objecting to the use of > synchronized without a related object: > > synchronized { > // do stuff > } > > This statement should be illegal. You must always specify a > synchronization context: > > synchronized(myMutex) { > // do stuff > }
I agree with that. I was just in too much of a hurry when I threw that code snippet together and left out the mutex. I was more concerned with what was in the synchronized block than how the lock was done. It could have been done with guard/autolock and RAII as far as I was concerned with regards to what I was trying to show. > For the rest, it seemed like the suggestion was that you could > just wrap a statement in any old synchronized block and all your > problems would be solved, which absolutely isn't the case. I certainly wasn't suggesting that all problems would be solved by a synchronized block. I was simply trying to show that in order to actually use a shared object, you have to cast away shared, and that means protecting the object with a lock of some kind. You then have the problem of making sure that no thread-local references to the object escape the lock, but at least shared then becomes useable. - Jonathan M Davis