On Mon, 14 Jun 2010, Tomek Sowi?ski wrote: > This is a continuation of a recent thread "Synchronized const methods" on > D.learn. > > Currently only one thread at a time can execute a synchronized method. But > think about D's const -- it's deep, so if a method is const, it can't possibly > mutate its object. So many synchronized const method calls could safely > look-but-not-touch the same object at the same time. > > The chain of questions that stems from the above is: > 1. Is letting many readers in on an object really safe? Know any > multi-threading quirk that would make sh*t hit the fan? > 2. If answer to 1. is yes, would there be room in the current implementation > of synchronized keyword for a readers-writer lock? > 3. If answer to 2. is yes, how do we tackle write-starvation? In a read-mostly > scenario the mutating thread may be held up forever. > > More on readers-writer lock: > http://en.wikipedia.org/wiki/Readers-writer_lock > > > Tomek
Const methods only prevent mutating 'this'. You can still call functions that mutate other state (via globals or passed in arguments). Additionally, I'm also a little concerned about the implications to application performance. Add one method that's non-const and suddenly the app performs somewhat differently and it's hard to tell why. It's an interesting idea, and still worth exploring, but my inclinations are that this should be explicitly setup rather than done behind the scenes. Later, Brad
