On Sunday, May 12, 2013 06:34:48 Domain wrote: > Sure, we can use synchronized block instead of synchronized > function. But it's inconvenient. Why not the compiler > automatically convert the non-synchronized function to > synchronized function when the object declare as shared?
The actual code generated for a synchronized function would be different, and automatically handling of locking like that would actually be very error-prone - particularly when you consider the potential for deadlocks. Do you really want to end up with deadlocks because the compiler chose to automatically insert locks where you didn't ask for them? Another thing to note is that on some level, shared code is _supposed_ to be inconvenient. You shouldn't be doing it often. It's supposed to be possible but not necessarily friendly. It's quite possible that we haven't hit the right balance on that, and it's too much of a pain to do right, but it was never intended that any of that be automatic or invisible. Code dealing with shared objects should be carefully segregated from normal code. synchronized was designed with the idea that you would create classes that were specifcally for synchronization and not that normal code would be synchronized. In fact, TDPL calls for making entire classes synchronized or not rather than individual functions (though it's not currently implemented that way in the compiler - you can still have both synchronized and unsynchronized functions in the same class). So, if you intended to use synchronized functions, you'd set it up so that the whole object was set up that way and only ever used that way. I suggest that you read the chapter on concurrency in TDPL. That particular chapter is actually available online for free: http://www.informit.com/articles/article.aspx?p=1609144 - Jonathan M Davis
