Sean Kelly wrote: > 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. > > It's an interesting idea but I'd recommend against it for a few reasons: > > 1. Acquiring, using, and releasing a reader lock is actually more > expensive than a plain old mutex so it isn't a good idea to use one just > because you can. A ReadWriteMutex is really for addressing convoying > problems on containers. > > 2. The typical implementation of a ReadWriteMutex doesn't permit recursive > up/downgrades from reader to writer and such. It's technically possible > to do this, but doing so requires a lot more machinery and consequently > trades away even more performance.
That shed some light, thanks. > That said, if you're inclined to experiment there's a ReadWriteMutex in > core.sync.rwmutex (which you already may know). I didn't know it even existed:) The library reference seems a bit broken. Some core modules are camouflaged as std.* (e.g. std.thread, std.gc is core.memory for some reason), core.sync is not even listed. http://www.digitalmars.com/d/2.0/phobos/phobos.html Tomek
