Tomek Sowiński <[email protected]> wrote: > 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
The Phobos wrappers exist for backwards compatibility, I suppose it's high time they were removed. I really need to see about bundling the druntime docs with the Phobos docs.
